An improved Test Control Architecture and Test Control Expansion for Core-Based System Chips Tom Waayers Philips Research Laboratories Prof. Holstlaan 4, M/S WAY-31 5656 AA Eindhoven, The Netherlands
[email protected]
Abstract This paper presents improvement of a core-based chip’s test control architecture that uses Std IEEE 1149.1 TAP to access core level register Test Control Blocks (TCB). We show enhancements for the register TCB, to improve its test coverage, to enable IEEE 1149.1 compliant RUNBIST and to optimize chip level TCB access. In addition, Test Control Expansion (TCE) is presented. TCE automatically validates test control architecture in a design netlist, and is capable of calculating chip level test mode initialization sequences.
1. Introduction ‘Divide and conquer’, a well-known strategy that was born in ancient times. Needless to say that it is still alive and an absolute must in today’s system chip design. Modern system chips are built by merging IP cores, which are often delivered from several companies. Each core providing company focuses on their own expertise. This enables the development of innovative, high quality products in reasonable time. Given the amount of resources active in the design domain, multiple cores can be developed in the same time frame. These cores find their way into multiple designs, serving a variety of application areas. The ease of merging IP delivered from more than one source, heavily correlates with the availability of a robust re-use strategy. Such a strategy leads to ‘conquer’ by not only ‘divide’ in the functional domain, but in the test domain as well. For this reason the IEEE P1500 Working Group [13] pursues a standard for testing embedded cores. It tries to define a standard that facilitates the test interoperability of IP cores from different sources. Ideally this results in a ‘plug & play’ environment in which tests delivered with a core can be executed, without modifications, even when this core is deeply embedded in a large system chip. The conceptual architecture for testing embedded cores in system chips, consists of a pattern source and sink, a test access mechanism and a core test wrapper [4]. These elements are often discussed in relation with test data reduction, test time optimization and test scheduling.
In this paper we deal with the accompanying test control. We present a test control concept that makes use of hardware structures, similar to the TCB defined by the Virtual Socket Interface Alliance (VSIA). This test control hardware also can be seen as a subset of the IEEE P1500 Wrapper Instruction Register (WIR). Besides improvement and new features in hardware we introduce a unique tool flow that is currently used to generate, and efficiently evaluate, test control for large system chips. The sequel of this paper is organized as follows. Section 2 gives an overview of prior work done in the domain of test control hardware. Section 2.1 introduces the Philips Test Control Architecture. In section 3 features are presented that improve the test coverage of both TCB and the logic it controls. It also describes a mechanism to implement test control for the standard IEEE 1149.1 runbist instruction. This section also presents an optimization feature for chip level Test Control access. Section 4 presents Test Control Expansion. This is a process that translates core level TCB initializations to chip level. Section 5 concludes this paper.
2. Prior Work In [1] a testability strategy is proposed that closely follows the design hierarchy, resulting in a hierarchical set of testable macros. It was identified that each macro comes with different types of scan chains, each having their own modes and thus their own control signals. Because the amount of modes is huge, having access to the accompanying control signals via bond-pads leads towards an unacceptable number of IC pins needed for test control. For this reason, a TCB was introduced to generate all control signals on-chip. The TCB was implemented as a finite state machine, dedicated to a given macro and its test requirements. The task of the presented TCB is to sequentially select macro-trees, each with their own TCB. The tests of one macro-tree are started by an enable signal. If the tests are finished, a ready signal is send back to the owner TCB. This way the whole process of testing a design becomes a hierarchical macro-tree traversing process.
ITC INTERNATIONAL TEST CONFERENCE 0-7803-8106-8/03 $17.00 Copyright 2003 IEEE
Paper 44.3 1145
Main drawback of the hierarchical concept presented, is the hard-coded test configurations and sequences. In practice there is often a need to add, change or re-order tests on the Automatic Test Equipment (ATE), after silicon tape-out. The Test Access Architecture defined by the VSIA [11], has an optional TCB. It can be viewed as an instruction register, as the values loaded into the TCB configure the test that is performed. The TCB is build from a shift and a shadow register to prevent random perturbations on control signals. Both registers are synchronous to one clock. An asynchronous reset of the TCB registers puts the logic it controls in functional operation mode. The scalable test architecture that is developed by the IEEE P1500 Working Group [13], contains a mandatory Wrapper Instruction Register (WIR). This WIR is a serial instruction register that is used to load pseudo static test control settings. It also comprises interface circuitry to other components, such as the Wrapper Boundary Register (WBR) and the Wrapper Bypass Register (WBY). Figure 1 shows the WIR architecture. The WIR can be accessed through the standard Wrapper Serial Port (WSP) by asserting the SelectWIR signal. In this mode the WIR is connected between the Wrapper Serial Input (WSI) and Output (WSO) for serial access. :%5 :'5 :6,
:%
update’ results in an undefined state of the TCB update register. To support RUNBIST we store its opcode in the shift register when the TCB is reset via the tcb_enable signal. When the reset is de-activated, the TCB enters its initial test mode. By holding the shift register content and applying an update action in initial test mode we enter the RUNBIST mode and self-test execution is started. The states and sequences an extended TCB can go through, are shown in Figure 8. The left state-transitions show standard operation that starts with the initial test mode followed by repeating sequences of shifting and updating new test modes. The right state-transitions show the RUNBIST sequence. After completion of the BIST, standard test mode sequences can be used. While integrating multiple cores in a design we want to be able to hookup TCBs from different cores in a single chain. All TCBs in this chain share the same control signals. This means that all TCBs must enter a pre-defined mode when the self-test sequence ‘reset -> update’ is applied. For this reason we mandate that all TCBs either load RUNBIST or IDLE in the shift register when the reset is activated. The IDLE opcode in this case equals the opcode of the initial test mode and is used for TCBs that do not control any BIST hardware or related clock switches. Paper 44.3 1149
3.3 Optimizing Test Control access In our test control architecture, each wrapped core comes with a single TCB interface. At chip level TCB chains are created by concatenation of core level TCB chains. Depending on the test strategy of a design, either one single or multiple chains are created. Each TCB chain is addressed by a dedicated TAP controller instruction. Note that all TCB chains share the same tcb_enable signal, generated by the TAP controller. This makes sure that the complete chip, including all embedded cores, operates either in application, or test mode. tcb_hold 0 1
tcb_tdi tcb_tck tcb_enable tcb_update
Shift register
BS
Update register
BU
tcb_tdo
TCB REG
tcb_tc
In core-based design-for-test flows we want to benefit from the fact that for both test data access and test control, standardized structures are used. To efficiently make use of a test control architecture in different design stages, tool support is needed to:
Test Control Signals
Figure 9: Basic TCB with bypass
A chip level TCB chain that contains all core level TCBs can become very long. In today’s system chips we already face over thousand control bits in total. Of course multiple TCB chains can be used to distribute cores over separate test control domains, each addressed by a dedicated TAP controller instruction. Having multiple TCB chains also has its drawbacks. It complicates test scheduling, because not only TCB content but also TAP controller instruction register content is involved in the pre-condition of a certain test. To enable efficient access to a subset of TCBs in a chain, we developed a TCB bypass feature. In Figure 9 a detailed implementation is shown.
7&% &25($
7&% &25(%
7&% &25(&
Figure 10: Example TCB bypass behavior
The TCB shift register is extended with a dedicated bypass shift register stage (BS) that has its input driven by a two input multiplexer. This multiplexer has one input connected to the shift register output and the other input directly connected to tcb_tdi. The latter creates a combinational path that bypasses the shift register. The select signal of the multiplexer is driven by a dedicated bypass update register stage (BU). The BS content is always loaded into the BU when a positive edge on the tcb_update clock occurs. The BU output not only controls the bypass multiplexer, it also masks the tcb_update clock of the TCB update register. Paper 44.3 1150
To keep the TCB bypass of a certain TCB activated while accessing other TCBs, opcode ‘0’ must be loaded in its BS. Loading logic ‘1’ de-activates the TCB bypass when a TCB update action is performed. In Figure 10 an example is shown in which three TCBs are concatenated in one chain. Core A and B have their bypass enabled. This results in efficient access to the TCB of core C.
4. Test Control Expansion
TCB
In application mode, the BU is set to logic value 1. This results in standard TCB behavior. The TCB bypass behavior is switched ‘on’, when a logic 0 is loaded in the BU. As a result the tcb_update clock of the update register is masked. This results in test control signals that drive stable pre-loaded values until the TCB bypass behavior is switched ‘off’ again. The logic value 0 loaded in the BU also selects the shift register bypass path. This results in a single register stage bypass between tcb_tdi and tcb_tdo, created by BS and an anti-skew element.
-
-
Implement the architecture: Standard structures like TCB and TAP controller can be generated and inserted in core and chip level modules. This results in a faster and less error-prone design process. Validate the architecture: Check the architecture by exploring a design netlist. This enables outgoing and incoming inspection during core and chip design. Use the architecture: Support test control at higher abstraction level, e.g. group test control bits in easy to reference test modes and calculate chip initialization sequences for test. This results in a faster and less error-prone test development and diagnosis process.
Our core-based design flows and tool support for test development, use concepts that were developed to support the Philips macro test strategy [2]. The basic idea of this strategy is that modules are all tested separately in a hierarchical design. The strategy distinguishes between test patterns and protocols. The protocol specifies formally how a single test pattern must be applied to a module-under-test. One of the key operations to support the macro test strategy is Test Protocol Expansion (TPE). TPE is the process of transforming local test protocols, described at terminals of a core, into global test protocols, described at terminals of a higher-level module (eg. chip level). This involves searches for test access paths along which test stimuli and responses can be transported to and from a core-under-test. If TPE is repeated throughout a design hierarchy, the chip level will be reached. Chip terminals are accessible for the ATE.
TPE uses a back tracking path search algorithm, which tries to find paths from input and output terminals of the module-under-test to input and output terminals of a surrounding module. Data terminals require dataindependent paths. A data-independent path is a path that is able to propagate signals irrespective of their value. Control terminals only need a path which is capable of transporting a certain value, defined in the test protocol. All paths must be conflict free, i.e. they should not share hardware during the same (relative) time slot. To perform TPE efficiently, an abstract view of the chip netlist is needed. Creating this abstraction must be done prior to executing the expansion process itself. In our flow, we first build a database of the chip level TAM. The TAM is formed by chip terminals, test muxing, and wiring, in combination with core level terminals, and scan chains. The TAM database content is build using a trace algorithm that hierarchically lists scan chains, starting at basic shiftregister instances or abstract chain descriptions that mask netlist details, or describes black-box modules. Before the tracing algorithm can start, first test control signals that define configurations of the TAM must be forced to their static values for a specific test mode. In our standard test control architecture we control all these signals from TCBs. This means that before building a TAM database for a certain test mode we first have to set all TCB outputs to the static values that belong to that test mode. In order to do this automatically we need a database that contains all TCB test mode information and the protocol to initialize the accompanying TCBs. So in conclusion, the pre-condition for efficient TPE is building a TAM database. The pre-condition for building a TAM database is building a TCB database. Building the TCB database can be combined efficiently with validating the test control architecture in case we do not use standard simulation techniques for this task. To have detailed feedback during validation, trace techniques based on symbolic simulation are preferred. For both TCB database creation and test control architecture validation we re-use techniques that are used for TPE. Instead of patterns and protocols implementing a test, we now deal with test modes and TCB initialization protocols implementing an initialization. We call the resulting process Test Control Expansion (TCE). TCE is the process of transforming a local TCB initialization protocol, described at the terminals of a module, into a global initialization protocol, described at the terminals of a higher-level module. Similar to TPE this is done repeatedly throughout a design hierarchy. Apart from validating the test control architecture, and calculating the TPE pre-conditions, TCE also results in a chip level initialization protocol and a set of chip level test
mode opcodes. These are used to construct initialization vectors during test assembly for both simulation and ATE. To support TCE in our tool flow, we added TCB constructs in our proprietary test data format. Similar capabilities go into the Core Test Language (CTL) that is being defined in IEEE Std. 1450.6 [14]. Amongst others, test data is used to annotate modules in a design netlist that implement scan chains, register TCBs or a TAP controller. Test data is also used to define protocols, and links to accompanying test pattern sets. In analogy to the constructs that define initial and expanded protocols [3], we added constructs to define TCB register and expanded TCB initialization protocols. A module definition in test data is used to re-model a cell in a netlist, and masks all its lower level instances. Figure 11 shows two parts of our design flow in which TCE is used, i.e. the core packager and the core integrator sub-flows.
TCB generator
hardware
TCB register test data
Insert in Core netlist
Core netlist
1149.1 generator
hardware
Insert Cores in Chip netlist
TAP controller test data
Core level test data
Insert in Chip netlist
TCE
Core level test data Core Packager TCE flow
Chip netlist
TCE
Chip level test data Core Integrator TCE flow
Figure 11: Test Control Expansion sub-flows
The core packager flow starts with the tool that generates standard TCB hardware. Besides the hardware, the tool also generates output in our own test data format. Multiple TCBs can be generated and inserted in a core netlist. The resulting core netlist and all TCB test data files are input to the TCE process. From the TCE result, a test data description at core level can be generated. The test control section of this data file describes a core level initialization protocol that covers all TCBs embedded in the core. The core integrator flow starts with the tool that generates standard IEEE 1149.1 hardware. The chip level test control architecture is defined using this tool, i.e the amount of TCB chains and TAP instructions that address the chains. This tool also generates output in our own test data format besides the hardware output. The chip netlist after insertion of cores and 1149.1 hardware, the TAP controller test data and all core level test data are input to the TCE process. From the TCE result, a test data description at chip level can be generated. This description defines the chip level initialization protocol and opcodes for chip test modes that are translated to initialization vectors during test assembly. Paper 44.3 1151
4.1 TCB generation As explained before, in our designs a lot of TCBs are embedded. To ensure that all TCBs comply to our standard, a tool has been developed that generates TCB hardware and accompanying test data view. The latter is very important because this guarantees consistent data for TCE. 7&%2873876
scan_enable; hold_inputs; hold_outputs; delaytest; bist;
To overcome this limitation we enabled hold behavior for TCB modules in test data. We defined a hold condition for test modes and accompanying TCB output values. A test mode is only valid after initialization in case the TCB hold condition is fulfilled, see Figure 13. Tracing of these hold conditions and initialization protocol conditions will prove the TCB control connections in the architecture and will contribute to the calculation of conditions for TPE.
7(6702'(7 < 2>
= = = = = =
[+]; [0]; [1]; [0]; [1]; [1];
! ! ! ! ! !
Test clock active Shift TCB data Hold TCB shift data Hold TCB output Update TCB Keep TCB enabled
} { tcb_update = [0]; tcb_enable = [1];
+ROG&RQGLWLRQ
}
2XWSXW{
Q[size-1:0] = tcb_tdi;
} Shift mode condition Shift
0RGH
Hold condition
0RGH
Test Mode
Initialization
0RGH 0RGH
tcb_enable
0RGH 0RGH
tcb_tck tcb_tdi
application initial intest_delay intest_stuckat intest_bist extest
{ { { { { {
Q[size-1:0] Q[size-1:0] Q[size-1:0] Q[size-1:0] Q[size-1:0] Q[size-1:0]
= = = = = =
[LLLLLL]; [LLLLLL]; [LHHLHL]; [LHHLLL]; [HHHLLH]; [LHLHLL];
} } } } } }
} tcbregister { Length = size; Clock = tcb_tck; ScanInput = tcb_tdi; ScanOutput = tcb_tdo; ShiftMode { tcb_hold=[0];tcb_enable=[1];tcb_update=[0]; }
&KDLQ
Mode Extest
tcb_hold tcb_update
} }
Q[-5:0]
Extest -9 -8 -7 -6 -5 -4 -3 -2 -1 0
1
2
3
4
5
6
7
cycle
Figure 13: Example TCB initialization protocol
From the defined test control signals and test modes, standard TCB hardware is generated. The tool creates a TCB by concatenating standard building blocks that are loaded from a library. Each building block implements the behavior of one single test control signal. Given the fact that a signal can only have four values (0,1,S,N), a slice can at most add 2 register stages to the TCB. The example showed in Figure 12, results in a register that has a length of 6 sequential elements. The control signal scan_enable needs two register stages. All other signals are only used to drive either a fixed one or a fixed zero. Paper 44.3 1152
Figure 14: Example test data: TCB register
To continue the architecture validation and TCB database creation, also the shift register input of all TCBs needs tracing towards core and chip terminals. For this purpose sequential chain behavior and its shift mode conditions must be part of the TCB test data view. Multiple TCBs in one chain, share the same control signals. As a result the update cycle is equal for all TCBs, which means that all TCB initialization protocols are right aligned in time. Supporting a reset cycle prior to shifting in the initialization protocol requires extended tracing capabilities. Tracing must be extended with calculation of the amount of shift mode cycles between reset and update. We decided to add a global reset sequence during test assembly instead.
In Figure 14 an example TCB register in our test data format is shown. The test data describes the TCB register, its initialization protocol, hold condition, opcodes and sequential chain behavior. The initialization protocol does not define the data to be shifted in. This is defined in multiple mode definitions. The register output values are defined by input values upon initialization in a list of output = input . The outputs get their fixed values after initialization and thus have no specified cycle.
developed in the past. The tool supports the creation of a TAP controller that controls multiple user defined TCB chains. Besides the standard boundary scan chain and TAP controller hardware, the tool also generates output in our own test data format. The test data output for a TAP controller describes conditions and resulting effects during TCE (InitializationMode) and during TPE (TestMode). The latter only describes fixed TAP controller output values. &HOO
TAP {
7UDQVIHU
It is important to observe that a hold cycle has been added between the shift and update cycles of the TCB initialization protocol. This is done to have a fixed protocol that fits into the TAP state-machine diagram. The latter is necessary to enable expansion to chip level terminals in case a TAP controller is used as master test controller.
{ = jtag_program_tcb; { -17: 2> = [1]; -17: 2> = [+]; -17: -10> = [01100001 ]; -12: -10> = [ 001 ]; -9: -6> = [ 1100 ]; -5: -1> = [ 0 ]; 0: 0> = [ 1 ]; 1: 2> = [ 10];
,QLWLDOL]DWLRQ0RGH &RQGLWLRQ
trst tck tms tdi tms tms tms tms
< < < < < < <
sir opcode -> sdr -> e1d -> rti
}
4.2 Expanding to Core level
{ tcb_enable tcb_enable tcb_enable tcb_hold tcb_hold tcb_hold tcb_update tcb_update tcb_update
(IIHFW
After finalizing a core netlist that has TCBs embedded, TCE can be performed to validate the TCB chain and to create test data that describes the initialization protocol at core level. This test data is delivered together with chain descriptions, test protocols and patterns from core-packager to core-integrator. It will be used during chip level TCE, TPE and test assembly for a complete system chip.
< -17: < -5: < 1: < -17: < -5: < 1: < -17: < -5: < 1:
-6> 0> 2> -6> 0> 2> -6> 0> 2>
= = = = = = = = =
[LLLLLLLLLLHH ]; [ H ]; [ HH]; [HHHHHHHHHHHH ]; [ L ]; [ HH]; [LLLLLLLLLLLL ]; [ L ]; [ LH];
} } 7UDQVIHU
{
= jtag_program_tcb; { tms = [0]; trst = [1];
7HVW0RGH &RQGLWLRQ
CORE_D { 7FE {
&HOO
}
{ tcb_tck tcb_hold tcb_update tcb_enable
,QLWLDOL]DWLRQ
[+]; [00000011]; [00000001]; [1];
} } }
}
Figure 16: Example test data: TAP controller
{ tcb_update = [0]; tcb_enable = [1];
+ROG&RQGLWLRQ
} ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ
}
{ tcb_enable = [H]; tcb_hold = [H]; tcb_update = [L];
(IIHFW
= = = =
application initial intest_delay intest_stuckat intest_bist extest
{ { { { { {
tcb_tdi tcb_tdi tcb_tdi tcb_tdi tcb_tdi tcb_tdi
= = = = = =
[000000];} [000000];} [010110];} [000110];} [100111];} [001010];}
tcbregister { Length = size; Clock = tcb_tck; ScanInput = tcb_tdi; ScanOutput = tcb_tdo; ShiftMode { tcb_hold=[0];tcb_enable=[1];tcb_update=[0]; }
&KDLQ
} }
Figure 15: Example test data: TCB expanded to Core
In Figure 15 the TCE result of expanding our example TCB is shown. The expanded TCB view in test data only describes initialization sequences. Output effects of the embedded TCB are no longer of interest at core level, as they only control local DfT structures that are masked by test data at core level. From all TCB register modes, core level initialization sequences have been calculated.
4.3 Expanding to Chip level To ensure that all our system chips comply with IEEE 1149.1, an in-house boundary scan generator tool was
The TAP controller transfer defined in test data assumes a start in the Run Test Idle (RTI) state. Our global reset sequence fulfills this pre-condition. The conditions and resulting effects of following InitializationMode sequence are defined: RTI -> Shift Instruction Register (SIR) -> Shift Data Register (SDR)->RTI. The TCB content is shifted during the SDR state. Protocols are executed in the RTI state. In case of multiple TCB chains, multiple instruction sequences will be combined to one chip level initialization sequence as a result of TCE. TestMode transfer conditions and resulting effects are used to fulfill the hold conditions of TCBs controlled by the TAP controller. The trace algorithm used during TCE starts at modules in the netlist that have a TCB register or expanded TCB view. Module inputs are back-traced to chip input terminals or to transfer effects of another module, e.g. a TAP controller. The latter results in new transfer conditions that need to be back-traced again until chip input terminals are reached. Module outputs are propagated to chip output terminals. The test data example shown in Figure 16 describes the behavior of TAP controller instruction jtag_program_tcb Paper 44.3 1153
that uses opcode 100 and addresses a TCB chain of length of six. The TAP controller view does not include the global reset that is needed to bring the system chip in a defined state after power-up. The TAP controller defined in IEEE 1149.1 uses a fixed state diagram [12]. Multiple sequences can be traversed through the diagram but, for loading TCB registers, we limit ourselves to the presented sequence. &HOO
CHIP { { trst tck tdi tms
{
= = = =
[1]; [+]; [001]; [01100001110000000110];
[2] Marinissen et al., “Testability and Test Protocol expansion in hierarchical macro testing”, European Test Conference, Rotterdam, The Netherlands, 1993, pp. 28-36
{
tms = [0]; trst = [1]; } ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ ,QLWLDOL]DWLRQ
}
application initial intest_delay intest_stuckat intest_bist extest
{ { { { { {
tdi tdi tdi tdi tdi tdi
= = = = = =
[000000];} [000000];} [010110];} [000110];} [100111];} [001010];}
}
Figure 17: Example test data: TCB expanded to Chip
In Figure 17 the result of expanding our example TCB to chip level is shown. The expanded view in test data again describes initialization sequences only. It is important to note that the clock cycles in the Initialization only determine relative timing of the initialization sequence. The timing values relate to an arbitrarily chosen refence point in time. The TCE trace algorithm found the chip level TAP being the interface to initialize test modes, as expected. Because of the tracing capability, we have very detailed feedback in case the test control architecture is broken somewhere in the design netlist. Finding these problems using simulation of hand-crafted initialization sequences is a tedious and time consuming job.
5. Conclusion and future work In this paper we presented improvements for a test control architecture that makes use of register TCBs under control of an IEEE 1149.1 TAP controller. We showed enhancements for the register TCB, to improve its test coverage, to enable 1149.1 compliant RUNBIST and to optimize chip level TCB access, using a TCB bypass feature. Besides hardware extensions, a model in a proprietary test data format was presented. This is used to automatically validate the test control architecture in a design netlist and to calculate chip-level initialization sequences using a new Test Control Expansion process. The work presented makes use of our own Philips internal TCB standard, and proprietary test data format. Currently we investigate the impact of using IEEE P1500 compliant hardware and the IEEE 1450.6 Core Test Language [14] instead. We have plans to validate these standards by practical experiments, using our tool flow. Paper 44.3 1154
This work has been partially funded through the European MEDEA+ program.
[1] Beenker et al., “A testability strategy for silicon compilers”, Test Conference, 1989. Proceedings. 'Meeting the Tests of Time'., International, Page(s): 660 -669, 29-31 Aug 1989
} +ROG&RQGLWLRQ
The author would like to acknowledge the contributions of the members of the Philips Core Test Action Group, and Jan Sr. Waayers for his silent support.
References
7FE
,QLWLDOL]DWLRQ
Acknowledgments
[3] Marinissen, Lousberg, “The Role of Test Protocols in Testing Embedded-Core-Based System ICs”, European Test Workshop, Constance, May 25-28 1999 [4] Y. Zorian, E.J. Marinissen, S. Dey, Testing Embedded-Core Based System Chips, Proceedings International Test Conference, IEEE, 1998, pp. 130-143. [5] E-J. Marinissen et al., “A Structured and Scalable Mechanism for Test Access to Embedded Reusable Cores”, in Proceedings International Test Conference, IEEE Computer Society Press, Washington, DC, pp. 284-293, October 1998. [6] L. D. Whetsel, "An IEEE 1149.1 Based Test Access Architecture For ICs With Embedded Cores", in Proceedings International Test Conference, pp. 69-78, Washington, D.C., USA, 1997 [7] B.I. Dervisoglu, “A unified DFT architecture for use with IEEE 1149.1 and VSIA/IEEE P1500 compliant test access controllers “, Proceedings Design Automation Conference, 2001 [8] Cheng-I Huang; Kuen-Jong Lee , “A hierarchical test control architecture for core based design”, in Proceedings of the Ninth Asian Test Symposium, Page(s): 248 –253, 2000. [9] S. Koranne et al., “A P1500 compliant programmable BistShell for embedded memories”, Memory Technology, Design and Testing, IEEE International Workshop, Page(s): 21 –27, 2001 [10]B. Vermeulen et al., “IEEE 1149.1-compliant Access Architecture for Multiple Core Debug on Digital System Chips”, Proceedings International Test Conference, IEEE, pp. 55-63, 2002 [11]VSI Alliance homepage - http://www.vsi.org/. [12]IEEE Computer Society. "IEEE Standard Test Access Port and Boundary-Scan Architecture – IEEE Std. 1149.1-2001", IEEE, New York, 2001 [13]IEEE P1500 - "Standard for Embedded Core Test (SECT)" homepage, http://grouper.ieee.org/groups/1500/. [14] IEEE P1450.6 - "IEEE 1450.6 Core Test Language (CTL)",
homepage, http:// grouper.ieee.org/groups/ctl/
