Abstract

A major challenge in realizing core-based system-chips is theadoption of adequate test and diagnosis strategies. this paperfocuses on the current industrial practices in test strategiesfor system-chips. It discusses the challenges in testingembedded cores, the testing requirements for individualcores, and their test access mechanisms. It also covers theintegrated test strategies for system-chips based on reusablecores. In addition to the state-of-the-art practices intestability schemes, this paper covers the currentstandardization efforts for embedded core test interfacemechanisms.

Keywords: Testing Embedded Core, Intellectual PropertyTest, System-on-Chip Test.

1: Introduction

Today’s embedded cores incorporated into system-chipscover a very wide range of functions, while utilizing anunprecedented range of technologies, from logic to DRAM toanalog. They often come in hierarchical compositions. Forinstance, a complex core may embed one or more simplecores. An example system-chip design is shown in Figure (1),where a cores of various functions are demonstrated. Thesecores typically come in a wide range of hardware descriptionlevels. They spread from fully optimized layouts in GDSIIformat to widely flexible RTL codes. Embedded cores arecategorized into three major types based on their hardwaredescription level: soft, firm and hard [15]. Each type of corehas different modeling and test requirements. The three typesof cores offer trade-off. Soft cores leave much of theimplementation to the designer, but are flexible and process-independent. Hard cores have been optimized for predictableperformance, but lack flexibility. Firm cores offer acompromise between the two.

The emerging process of plug-and-play with embedded coresfrom diverse sources faces numerous challenges in the areasof system-on-chip design, integration, and test. This paperanalyzes the test and diagnosis challenges and discusses thecurrent solutions to create testable core-based system-chips.The paper mainly covers the common practices in the

industry and shed light on the ongoing efforts to containtoday’s challenges.

Figure (1) System-Chip consisting of hierarchical cores andUser Defined Logic (UDL)

In section 2, the paper discusses the testing challenges incore-based system-chips. Section 3 describes the existingstrategies to address core internal test. Section 4 coversembedded core peripheral access mechanisms. Section 5discusses the overall system-chip test and diagnosissolutions. Finally, Section 5 concludes the paper.

2. System-Chip Test Challenges:

In this section, the main test challenges in system-chips areanalyzed and compared to the conventional system-on-board(SOB) ones. In addition to the major differences here, wehave to note that system-chips do also share the typicaltesting challenges of the traditional deep-submicron chips,such as defect/fault coverage, overall test cost and time-to-market.

Even though, the design processes in both paradigms, i.e. insystem-chip (SC) and SOB, are conceptually analogous, butthe test processes are quite different. For conventional SOB,the manufacturing and test of a chip takes place first, prior tothe PCB assembly and test. A chip in this case could be astandard IC or a user defined ASIC; whereas in a core-basedsystem-chip case, there is only a single manufacturing andtest instance that takes place for the whole system-chip, seeFigure (2). In this case, the individual cores and theirsurrounding User Defined Logic (UDL) are designed

DSPUART core

USB core

MPEGDRAM

UDL

SRAM

SRAM

coreEmbedded

core

DMA

ComplexCore

UART core

UDL

UDL

System-Chip Test Strategies

Yervant Zorian

LogicVision, Inc.San Jose, California, USAzorian@logicvision.com

35th Design Automation Conference ®Copyright ©1998 ACM

1-58113-049-x-98/0006/$3.50 DAC98 - 06/98 San Francisco, CA USA

Permission to make digital ro hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DAC 98, June 15019, 1998, San Francisco, CA USA ISBN 1-58113-049-x/98/06…$5.00

752

individually first. Next, they are all integrated into an SC.And only then, the composite manufacturing and test steps dotake place. See the comparison of the two processes in Figure(2).

Figure (2) Multi-stage testing for conventional System-on-Board versus single stage System-Chip Test

2.1 Core Internal Test Challenges:

Various test techniques are used for core internal testing, suchas functional test, scan, BIST, etc. They typically require twoelements:

a. A set of test patterns to be applied to or captured from thecore peripheries (core input/outputs). These test patterns arecomposed of data and control patterns and are generated andevaluated by a test resource (on-chip or off-chip).

b. Internal design-for-testability structures which correspondto the test technique used in the core (e.g. scan chains, testpoints), if any.

The data patterns are the actual stimulus and response signals;whereas the control patterns specify the test flow, i.e. how toapply and capture the data patterns. Selecting certain internaltest mode is considered static control; whereas a shift andapply sequence in a scan protocol is considered dynamiccontrol. Static and dynamic test control patterns, in additionto the data patterns, are applied to the core peripheries toexecute a given internal test mode.

A core is typically the hardware description of today’sstandard ICs, e.g. DSP, RISC processor, or DRAM core.Even though, a given core is not tested individually as instandard ICs, and instead is tested as a part of the overallsystem-chip, see Figure (2), but still, the preparation of a coreinternal test is typically done by the core creator. Because, thecore integrator in most cases, except for soft cores, has verylimited knowledge about the structural content of the adoptedcore, and hence deals with it as a black box. Therefore he/shecan not prepare the necessary test for it. This is especially trueif a core is a hard one or is an encrypted Intellectual Propertyblock. This necessitates that the core creator prepares theinternal testability, i.e. the DFT or BIST structures and thecorresponding test patterns, and delivers it with the core.

Another core creator function is to determine the internal testrequirements of the core without knowing the target processand application. For instance, which test method needs to beadopted (e.g. BIST, scan, Iddq, functional test), what type offault(s) (e.g. static, dynamic, parametric) to target and whatlevel of fault coverage is desired. In SOB, a chip’s ppmfigures are known prior to the PCB assembly. Hence, the testmethod and desired fault coverages are predeterminedaccordingly. But in system-chips, a core creator might notknow the target process and the desired quality level. Hence,the provided quality level might or might not be adequate. Ifthe coverage is too low, the quality level of the system-chipis put at risk, and if it is too high the test cost may becomeprohibitive (e.g. test time, performance, area, power).Furthermore, different processes have different defect typedistributions and levels of defect.

Furthermore, in system testing, the failure mechanisms differfrom those in production and the test time and powerrequirements (e.g. for BIST) may be different. Hence, a coreshould be well characterized with respect to the test and faultcoverage. Ideally, the internal test should be a composite onecontaining modular sections with different characteristics.These modular sections can be switched on or off accordingto the target process and application. Different internal coretest approaches are discussed in Section 3.

Finally, the core internal test prepared by a core creator needto be adequately described, ported and ready for plug andplay, i.e. for interoperability, with the system-chip test. For aninternal test to accompany its corresponding core and beinteroperable, it needs to be described in an commonlyaccepted, i.e. standard, format. Such a standard format iscurrently being developed by the IEEE P1500 and referred toas standardization of a core test description language(CTDL).

2.2 Core Test Access Challenges:

Another key difference between SOB and system-chip is theaccessibility of component peripheries, i.e. accessing primaryinput/outputs of chips and cores, respectively. With SOB,direct physical access to chip peripheries, i.e. pins, istypically available to use probing during manufacturing test;whereas for cores, which are often deeply embedded in asystem-chip, direct physical access to its peripheries is notavailable by default, hence, an electronic access mechanismis needed. This access mechanism requires additional logicand wiring to connect core peripheries to the test resourcesdefined in Section 2.1. The logic block performs switchingbetween normal mode and the test mode(s) and the wiring ismeant to connect this logic block which surrounds the core tothe test resource.

1. Peripheral Access Block: is the switching logic thatsurrounds the core, as shown in Figure (3). This is sometimesalso called a test collar or wrapper. This block contains a TestAccess Mechanism (TAM) dedicated to applying and

IC Design

IC Manuf.

SOB Design

IC Test

ASIC Manuf

ASIC Design Core DesignUDL Design

ASIC Test

SOB Manuf.

SOB Test

SC Integration

SC Manuf.

SC Test

System-on-Board (SOB) System-Chip (SC)Process Process

753

capturing test data patterns, and a Test Control Mechanism(TCM) for dynamic and static test control patterns. Thecontent of a Peripheral Access Block is typically compatiblewith the core internal test technique and is optimized for areaand performance constraints, are summarized in Section 4.Test control, as shown in Figure(3), is necessary for a givenperipheral access block to select (i.e. enable and disable) thepaths according to the desired mode.

2. Test Access Path: connects the input/output orbidirectional cells of the TAM and static and dynamic signalsof the TCM to the test resource (off-chip or on-chip). The testresource as indicated earlier contains the necessary test dataand control patterns. Figure (3) demonstrates three possibleaccess paths connecting core inputs P1, P2, and P3 to threepossible test resources T1, T2, T3, while passing via the TAMof the Peripheral Access Block. The first test resource isbased off-chip, e.g. functional patterns applied from anAutomatic Test Equipment. T2 is connected to an on-chip testresponse. This may be a BIST Test Pattern Generator [1], afunctional resource [2], or an on-chip bus [14], etc. Finally,T3 is connected to a test resource (test access mechanism)internal to the Peripheral Access block, such as a scan flipflopfrom a neighboring cell supplying serialized (functional orstructural) patterns. N1, N2, and N3 are normal mode inputsto the embedded core.

.

Figure (3) Embedded Core Accessibility

In addition to the normal mode and core internal test modes,a System-chip often requires several other test related modes.The TCM receives the static test control patterns and providesnecessary modes, i.e. configuration, at the Peripheral AccessBlock. One such mode is the core external test. The role of anexternal test is to test the interconnect faults between thecores in a System-chip (e.g. interconnect faults between theDSP core and the Embedded DRAM in Figure(4)). Also, coreexternal test is needed to participate in the UDL test, byproviding controllability and observability to the UDLperipheries through the Peripheral Access Block of aneighboring core, such as the DSP core in Figure (4).

In addition to applying and capturing test patterns duringinternal and external test modes, the Peripheral Access Blockcan also be utilized for core isolation. Typically, a core needsto be isolated from its surroundings in certain test modes.Core isolation is often required on either the input or theoutput side. If it is on the input side, it can put the core into asafe-state by protecting the core under test from externalinterferences (from preceding cores or UDL). On the outputside, it protects the inputs of the superseding blocks (cores orUDL) from undesired values (e.g. random patterns applied totri-state buffers creating bus conflicts). This is done bycontrolling the core outputs and putting them in tri-state mode(core in Hi-Z state).

Figure (4) Embedded Cores with Peripheral Access

Sometimes, other core isolation modes are also required toput a core in a stand-by mode, or low power dissipation mode,or ByPass mode [5][11], or finally to control the currentsupply of a core, if Iddq testing is used in the System-on-chip.

The Peripheral Access Block being an interface blockbetween a core and its surrounding logic (UDL or othercores) provides the necessary support for the above accessand isolation modes. It allows these modes to be selectedthrough the mode control protocols which control theswitching capabilities of the Peripheral Access Block. InSection 4, this paper summarizes popular testability strategiesto provide peripheral access for embedded cores. Becausecores are getting imported from diverse sources, a commonset of TAMs and TCMs are required. A scalable architecturewith such capabilities is pursued by the IEEE P1500standardization effort [12].

2.3 System-Chip Test and Diagnosis Challenges:

One of the major challenges in the SC realization process isthe integration and coordination of the on-chip test anddiagnosis capabilities. If compared to SOB, the system-chiptest requirements are far more complex than the PCBassembly test, which consists of interconnect and pintoggling tests. The SC test, as in Figure (2), is a singlecomposite test. This test is comprised of the individual coretests of each core, the UDL test, and the test of theirinterconnects. As discussed earlier, each individual core or

CoreP1

P2

P3

Embedded N1

N2

N3

T1

T3

TestControl Patterns

Peripheral Access Block

System-

T2

External

ResourceTest

Test Access Path

Chip

TCM

DSPUART core

USB core

MPEGDRAM

UDL

SRAM

SRAM

coreEmbedded

core

DMA

UART core

UDL

UDL

754

UDL test may involve surrounding components. Certainperipheral constraints (e.g. safe-mode, low power mode,bypass mode) are often required. This necessitatescorresponding access and isolation modes.

In addition to the test integration and interdependence issues,the SC composite test requires adequate test scheduling. Thisis needed to meet a number of chip level requirements, suchas total test time, power dissipation, area overhead, etc. Also,test scheduling is necessary to run intra-core and inter-coretests in certain order not to impact the initialization and finalcontents of individual cores. With the above schedulingconstraints the schedule of the composite SOC test is created.

The static test control for individual Peripheral AccessBlocks contribute to the execution of the composite test. Achip level static test control network is required to run thecomposite test and apply/capture the necessary on-chip andoff-chip test patterns (i.e. data patterns and dynamic control).

3. Embedded Core Test Strategies:The test preparation function for cores crosses theboundaries, from core creation phase, to SC integration, tosilicon fabrication phase. In each phase a portion of theoverall test is completed. Typically, the core internal test isprepared during core creation. The extent of the corepreparation in this phase depends on the core type, i.e. soft,firm, or hard. In some cases, full DFT needs to beincorporated in the core creation phase, and in others only testscripts and benches are generated in this phase. The testinformation transfer from one phase to the other, i.e. from oneplayer to the other, requires standardization in order toguarantee interoperability and ease of plug-and-play.

Selecting an adequate test strategy for an embedded core,such as BIST, ATPG/scan, or functional patterns, is not verydifferent then selecting a test method for a conventionalASIC. Here, the issue is that the function of preparing a testfor an embedded core is distributed between the core creatorand user. The extent of their involvements depends on thehardware description level of the core. If the core ismergeable with the User Defined Logic (UDL), than the coreintegrator has more flexibility in identifying andimplementing a core test method; whereas if the core is non-mergeable then the core creator has a much larger role indetermining and incorporating the core test method(s).

3.1 Mergeable Cores:

A core is defined as mergeable if it is a soft or firm (RTL orgate level) and can be combined with its surrounding randomlogic via standard flow without the need to create an isolationcolar (i.e. Peripheral Access Block) between itself and theUDL around it. In this case, the internal test method is notpre-defined during the core creation stage. The coreintegrator merges the core with the surrounding logic andthen applies the same test method (e.g. scan, ATPG, BIST) onthe merged logic, i.e. the core and the UDL [7]. Figure(5)

shows the RTL level MPEG core of Figure (4) merged withthe neighboring UDL to create an extended UDL for testpurposes. In the creation phase, the extent of test preparationfor mergeable cores is limited to passing audits, generatingDFT scripts, running fault simulation with the selected teststrategy to estimate the fault coverage and the vector counts.Describing the above test related information by the corecreator and porting it to the integrator is required.

3.2 Non-Mergeable Cores:

A core is considered non-mergeable if it can not be absorbedby its surrounding logic. Hence, it remains as a distinct entity.This happens either because the core hardware descriptionlevel is different from the one used in the surrounding logic.For example, a layout level DSP core shown in Figure (5) cannot be merged with the RT level surrounding UDL; or thecore uses a different technology, such as DRAM, Flash, RFor analog; or the core needs to remain isolated for IPprotection. Hence, it is encrypted.

In the case of non-mergeable cores, typically the internal coretest is incorporated mainly during the core creation phase andit is based on the target technology. In addition, the history ofthe core may have an impact on the internal test strategy. Forinstance, almost all memories today tend to use BIST. Hence,providers of embedded memory generators typicallyincorporate BIST wrappers in the memory core design [3].

The basic core test strategies used for mergeable and non-mergeable cores are typically the same as the ones used inconventional ASICs today. They either depend on externalresources or are self-contained with minimal need forexternal test patterns. The tests that require external patternsare based on functional test patterns or structural (ATPGgenerated) patterns. The functional patterns are created fordesign verification purposes and typically do not providehigh fault coverage, especially for large cores. Various corestoday do provide functional vectors with the delivery of acore. Examples of such cases are RISC cores, some memorycores, and analog cores.

ATPG generated patterns are based on structural testing,hence provide measurable fault coverage. But they do nottypically achieve high fault coverage unless coupled with aDFT approach, such as scan. In such a case, the scan chain ispre-synthesized during the core creation stage of a non-mergeable core, and during the integration stage formergeable cores. ATPG patterns are often generated by thecore user for un-encrypted cores. Typically, ATPG patternstarget stuck-at faults, and sometimes performance and Iddqfaults are also targeted. Certain processor and peripheralcores are delivered today with scans and ATPG patterns.

The problem with external test pattern based strategies is thatthey typically require large test volumes and need complexdynamic test control protocols to get stimulus to cores, toreceive responses from cores and to set up the necessary

755

control to execute the test on a core. A promising strategy thatminimizes such requirements is BIST. It generates andevaluates the test patterns on-chip, hence does not requireporting of test vectors from the core creator to the integratorand then to the fabricator. BIST is an autonomous testingmethod and is considered ideal for core-based systems.

In addition to providing the on-chip test resource, BISTsimplifies peripheral access complications, since it requires asimple interface and allows re-use of the core as a self-contained block. Today’s BIST schemes are mature enoughin terms of providing very high fault coverages. They alsoenhance the diagnosability, while allowing IP protection.

The core test scheme has to provide modular interface toallow integration of hierarchical test control scheme andallow potential sharing of test resources at higher levels.

Figure (5) System-Chip with Core Internal Test, PeripheralAccess Blocks and Core Test Interface

With a number of test strategies used for core internal test,there seems to be no possibility for standardizing an internaltest method. However, the delivery mechanism of the coretest from core providers to core integrators need to bestandardized. This may happen through standardizing theinterface mechanism between the core and the system-on-chip, as pursued by IEEE P1500 [12]. Such a commonmechanism definitely helps create interoperability of coresfrom diverse sources.

4. Core Peripheral Access Mechanisms:

Typically, cores are deeply embedded in a system-chip. Inorder to apply or exercise the test of a given core, access to itsperipheries is necessary. Such an access un-embeds the core,hence providing full controllability and observability to itsperipheries. In addition to accessing, this provides effectiveisolation for IP protection and for putting the core and thesurrounding logic in safe modes. A peripheral access arounda core fully contributes to the test of the surrounding UDL, byproviding observability to the core inputs and controllabilityto the core outputs.

Traditionally, there are three major peripheral accesstechniques.

4.1 Parallel Direct Access:

The technique is based on parallel access to the core I/Os byeither using dedicated chip level terminals or by sharing chipterminals while multiplexing and demultiplexing them withother signals. This approach, which is termed as starapproach, is popular when the number of cores is very limitedand the number of chip pins is more than the core pins. Butwith the continuous increase in the ratio of core terminals tochip terminals, this peripheral access technique is reaching itslimits. A number of proprietary techniques exist today to mapcore peripheries to chip primary input/outputs, even if thelater is smaller in number. A major disadvantage in thisaccess mechanism is its very high routing cost. Also, specialattention need to be applied if at-speed testing is required dueto problems with access path delays, skews, etc.

4.2. Serial Scan Access:

The second technique for peripheral access is based onserialization of test patterns. A scan chain around the coreallows indirect but full access to all the I/Os of a core. This iscalled ring access mechanism. The rings can be internal orexternal to the core and can be implemented by the corecreator or the integrator. In addition to accessing the core,such a ring also provides effective isolation from thesurrounding host logic, which may be necessary to rundifferent tests in the core and its surrounding logic. Thecomplexity and hardware requirements for the ring approachis acceptable for today’s system-on-chips and it remainsindependent of pin limitations. The use of Boundary-ScanIEEE 1149.1 as a serial access mechanism has been used byfew core providers such as ARM and TI [16].

The routing cost of this serial approach is far less than theprevious one. Also, the serial approach allows effectiveisolation and UDL test if the scan chain is used in its externaltest mode. The two negative aspects of this approach are thetest time increase, due to serialization, and the arbitrary signalswitching during scan (control and clock signals need to holdscan cell output stable).

Several DFT approaches were introduced to minimize thehardware cost of the serial scan ring around a core, by usingexisting functional flip-flops, mixing internal and externalFFs, or using compaction and expansion [4] [13]. In realisticexamples often a combination of serial and parallel accesscells are used for a given core, where the data patterns areapplied through the serial ring, whereas the clocks andcontrol signals are asserted via parallel access.

4.3. Functional Access:

The third technique for peripheral access is based on usingthe surrounding logic to propagate and justify the necessarytest patterns [2] This can be either based on existing normal

UDL

DSPUART core

USB Scan

TAP

DRAM

UDL

SRAM

SRAMBIST

DMA

UART Funct.

BIST

Scan Funct

BIST

TEPBSR

UDL

756

mode logic put in transparency for core test purposes [2], orbe based on using existing DFT mode, such as scan chains inthe surrounding logic. Even though, the cost of extrahardware is very low, this approach becomes complicated ifthe surrounding logic has deep functional paths and requiressophisticated protocols for test pattern translation.

The timing impact of a peripheral access mechanism iscritical. The path delay created by peripheral access logic andthe skews introduced in the access path need to meet therequirements of core test timing constraints.

The ring based technique remains the most realistic option forperipheral access. The ring approach provides access to runinternal BIST and internal scan for each core. It also helpstesting the surrounding logic using the ring registers.

5. Test and Diagnosis for System-Chips:

At the system-chip level, several test related functions areperformed. This includes the test for UDL, the assembly ofthe composite test, the creation of the test and diagnosis testdata and control network. All the above capabilities areutilized during fabrication. Also, at this phase, the DFTcircuits are used for silicon debug and diagnosis.

The system-chip test capabilities are integrated by connectingthe test facilities of each core and the DFT of the surroundinglogic under one chip level mechanism. This can be realizedby either multiplexing the test access paths of individualcores with the primary input/outputs of the chip [8], or byconnecting the test access paths to chip level test postingbuses [14]. Typically, the chip level control circuitry ishooked to the Boundary-Scan port of the chip. A test sessionfor the system-chip has to be composed of intra-core testingto guarantee that each core has been manufactured correctly,and an inter-core testing throughout the surrounding logic.The test execution schedule has to take into account severalvariables such as test time, power dissipation, noise duringtest, and area optimization [17].

In addition to the composite SC test, which is meant to beused as manufacturing test, other test, debug and diagnosismodes are often required. For instance, test modes arerequired for field testing and silicon debug modes for the SCdevelopment. Furthermore, diagnostic modes are often verycritical to the production of SCs. They are required to identifyfailed cores in some cases to determine the internal failures toeach core. Fault isolation requirements may impact theadopted internal core test strategy. In certain cases, theidentification of a failed core may not be possible, due to thefact that a core passed its individual intra-core tests, but thecomposite test detects an inter-core fault, such as aninterconnect fault or a delay fault.

6. Conclusion:

This paper presents a number of testing challenges facingcore-based system-chips. It identifies three major aspects to

testing core-based systems and describes the test strategiesused for each case. These are creating adequate and portablecore internal tests; providing core accessibility; and creatingan integrated test and its control mechanism for the overallsystem-chip manufacturing.

References:[1] V.D. Agrawal, C.J. Lin, P.W. Rutkowski, S. Wu, Y. Zorian,

"Built-In Self-Test for Digital Integrated Circuits”, AT&TTechnical Journal, Vol. 73, No. 2, p. 30, March 1994.

[2] F. Beenker, B. Bennetts, L. Thijssen, "Testability Concepts forDigital ICs - Macro Test Approach” Volume 3 of Frontiers inElectronics Testing. Kluwer Academic Publishers, Boston,1995.

[3] R. Chandramouli, S. Pateras, “Testing Systems on a Chip”,IEEE Spectrum, pp. 42-47, Nov. 1996

[4] K. De, “Test Methodology for Embedded Cores which ProtectsIntellectual Property”, VTS 97, pp. 2-9.

[5] I. Ghosh, N. Jha, S. Dey, "A Low Overhead Design forTestability and Test Generation Technique for Core-BasedSystems", Proc. ITC, pp. 50-59, Nov. 1997.

[6] R.K. Gupta, Y. Zorian, "Introduction to Core-based SystemDesign", IEEE Design & Test of Computers, Vol. 14, No. 4,Oct.-Dec. 1997.

[7] S.G. Hemmady, T.L. Anderson, Y. Zorian, "Verification andTesting of Embedded Cores", Proc. Design SuperCon, On-Chip Design, S122-1-19, Jan. 1997.

[8] V. Immaneni, S. Raman, "Direct Access Test Scheme- Designof Block and Core Cells for Embedded ASICs", Proc. IEEEITC, pp. 488-492, Sept. 1990.

[9] M. Hunt, J.A. Rowson, “Blocking in a System on a Chip”,IEEE Spectrum, pp. 35-41, Nov. 1996.

[10] B.K. Koenemann, K. Wagner, "Test Sockets: A TestFramework for System-On-Chip Designs", IEEE TTTCEmbedded Core Test TAC Study Group, April 1997.

[11] E.J. Marinissen, M. Lousberg, "Macro Test: A Liberal TestApproach for Embedded Reusable Cores", IEEE TECS, Nov.1997.

[12] Y. Zorian, "Test Requirements for Embedded Core-basedSystems and IEEE P1500", Proc. IEEE ITC, pp. 191-199, Nov.1997

[13] N. A. Touba, B. Pouya, “Testing Embedded Cores UsingPartial Isolation Rings”, Proc. of the 15th IEEE VLSI TestSymposium, pp. 10-15, April, 1997.

[14] Varma, P., Bhatia, S., "A Structured Test Re-Use Methodologyfor Systems on Silicon", IEEE TECS Workshop, Nov. 1997.

[15] “Virtual Socket Interface Architectural Document”, VSIAlliance, Nov. 1996.

[16] L. Whetsel, "An IEEE 1149.1 based Test Access Architecturefor ICs with Embedded IP Cores", Porc. Int’l Test Conference,Nov. 1997.

[17] Y. Zorian, "A Distributed BIST Control Scheme for ComplexVLSI Devices", Proc. of the 11th IEEE VLSI Test Symposium,p. 6-11, April 1993.

757