Paper 24.1 at IEEE International Test Conference (ITC’99), Atlantic City, NJ, USA, September 28-30, 1999
Towards a Standard for Embedded Core Test: An Example Erik Jan Marinissen
Yervant Zorian
Rohit Kapur
Tony Taylor
Lee Whetsel
Philips Research Eindhoven, NL
LogicVision San Jose, CA
Synopsys Sunnyvale, CA
Fluence Fremont, CA
Texas Instruments Dallas, TX
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Abstract Integrated circuits are increasingly designed by embedding pre-designed reusable cores. IEEE P1500 Standard for Embedded Core Test (SECT) is a standard-under-development that aims at improving ease of reuse and facilitating interoperability with respect to the test of such core-based ICs, especially if they contain cores from different sources. This paper briefly describes IEEE P1500, and illustrates through a simplified example its dual compliance concept, its Scalable Hardware Architecture, and its Core Test Language. Note that this paper provides a preliminary, unapproved view on IEEE P1500. The standard is still under development, and this paper only reflects the view of five active participants of the standardization committee on its current status.
1 Introduction
interconnect in between the cores, but also the cores themselves. Test development for cores requires a lot of knowledge of the core internals. The core user typically neither has this knowledge, nor wants to have it; he/she just wants to use the core, without spending too much time and effort on the core implementation. Therefore, we assume that the core provider will deliver with the core design itself a set of tests for the core. The core user should assemble a chip-level test out of the pre-defined tests for the various cores and additional tests for non-core chip circuitry. A test as described above, in which cores are tested as stand-alone units, is called a core-based test.
Until recently, most electronic systems consisted of one or multiple printed circuit boards, containing multiple integrated circuits (ICs) each. Recent advances in IC design methods and manufacturing technologies allow to integrate these complete systems onto one single IC. These so-called system chips offer advantages such as higher performance, lower power consumption, and smaller volume and weight, when compared to their traditional multi-chip equivalents. System chips are typically very heterogeneous, in the sense that they contain mixed technologies, such as logic, memories in various flavors, and analog [1]. Many system chips are designed by embedding large reusable building blocks, commonly called cores. Design reuse offers to speed up the design and allows import of external design expertise. The functions provided by cores include CPUs and DSPs, serial interfaces, modules for interconnect standards such as PCI, USB, and IEEE 1394, graphics computation functions such as MPEG and JPEG, and memories [2].
Testing of core-based system chips brings forth several new challenges [4, 5]. These include the following. 1. Core-Internal Tests. With features sizes of 100 nm and smaller, clock frequencies of 2 GHz and higher, and power supplies as low as 1.2 V, the development of high-quality, but relatively inexpensive tests for cores is an enormous challenge. Traditional fault models and related test pattern generation tools are increasingly inadequate, as noise, signal delay, and crosstalk are becoming more important [6].
Usage of embedded cores divides the IC design community into two groups: core providers and core users. In traditional Systemon-Board (SOB) design, the components that go from provider to user are ICs, which are designed, manufactured, and tested. The user of these components is only concerned with the design, manufacturing, and testing of his system, using the components as fault-free building blocks. Testing is limited to manufacturing defects in the interconnect between the components. In Systemon-Chip (SOC) design, the components are cores. Independent of whether these cores are delivered as soft (RTL code), firm (netlist), or hard (layout) cores, they are design descriptions only, not yet manufactured or tested [3]. The core user is responsible for manufacturing and testing the entire system chip, i.e., not only the
2. Core Test Knowledge Transfer. The total chip test development now is a (either in time or place) distributed effort, which requires transfer of information regarding the core tests from core provider to core user. This might include information regarding coreinternal DfT, test modes and corresponding test protocols, fault coverage, test pattern data, etc. 3. Test Access to Embedded Cores. A core is typically deeply embedded in the system-chip design. In order to run its tests, which are defined at the core 1
Marinissen, Zorian, Kapur, Taylor, and Whetsel
2
terminals, we need a test access mechanism to link the test pattern source (either an off-chip ATE or on-chip BIST) to the core inputs, and vice versa to link the core outputs to the test pattern sink (again, either ATE or BIST) [7]. 4. System Chip Test Integration and Optimization. The overall system-chip test should cover the reused cores, the user-defined logic, as well as the interconnect logic in between. While creating the chip-level test, the system-chip integrator is confronted with many optimization issues, regarding trade-offs between test quality and costs for area, performance, and power, and test [6]. This paper describes the current status of IEEE P1500 Standard for Embedded Core Test (SECT). IEEE P1500 SECT is a standard-under-development that focuses on the critical aspects of ease of reuse and interoperability with respect to testing of cores originating from distinct core providers. IEEE P1500 does so by standardizing the second and third challenge listed above, namely the core test knowledge transfer and the test access to embedded cores. The sequel of the paper is organized as follows. Section 2 gives a brief background on IEEE P1500. Section 3 explains the dual compliance concept that P1500 uses to obtain choice and flexibility. Section 4 gives an overview of the core test wrapper and how it fits into a chip-level test access architecture and Section 5 outlines the core test language CTL. In Section 6 the P1500 standard is shown in action, by means of a simplified example core. An originally ‘bare’ core is taken through two subsequent compliance levels of P1500, and the corresponding CTL programs and architecture are shown. Section 7 concludes this paper.
2 IEEE P1500 Working Group History In September 1995, the Test Technology Technical Council (TTTC) of the IEEE Computer Society initiated a Technical Activity Committee on embedded-core test, in order to identify common needs in this domain. After several meetings in conjunction with major conferences, it has concluded that there were indeed common needs and hence a desire for standardization [8]. In June 1997 the IEEE Standards Board granted permission to start a standards activity and this was then the official start of IEEE P1500, also referred to as ‘Standard for Embedded Core Test’ (SECT). Mission In order to improve efficiency of both core providers and core users, the IEEE P1500 standard should facilitate the interoperability with respect to testing when cores of different providers come together in one SOC. P1500 does not cover the core’s internal test methods or DfT, nor SOC test integration and optimization. These are completely in the hands of core provider or core user
respectively, and not suited for standardization due to the fact that their requirements differ for different cores and SOCs. Instead, IEEE P1500 focuses on standardizing those areas which are at the interface between core provider and core user. These involve (1) the core test knowledge transfer and (2) the test access to embedded cores. Through a scalable standard, IEEE P1500 hopes to contribute to ease of plug-n-play for testing, while maintaining the required flexibility to cope with different cores and system chips. Organization IEEE P1500 has active participation from leading experts in relevant industry segments, such as systems companies, EDA vendors, core providers, IC manufacturers, and ATE suppliers. The detailed technical work of P1500 is carried out by several Task Forces. The IEEE P1500 Working Group holds bimonthly public meetings, often organized in conjunction with major conferences. The Working Group meetings are announced at the P1500 web site [9], where one can also find the minutes and presentations of past meetings. The two main elements of the IEEE P1500 standard are a language, called Core Test Language (CTL) and a scalable core test architecture. The first is developed by the P1500 CTL Task Force and meant to standardize the core test knowledge transfer. CTL is based on another IEEE standard language, viz. IEEE Std. 1450.0, the Standard Test Interface Language (STIL) [10, 11, 12], which is extended to accommodate specific core test constructs. It has been decided not to standardize source, sink, or TAM (Test Access Mechanism, the test access ‘highway’ from source to core to sink) [7]. With respect to test access to embedded cores, P1500 only standardizes the test wrapper around the core and its interface to one or more TAMs. The design of this wrapper is carried out by the P1500 Scalable Architecture Task Force. Other P1500 Task Forces focus on Linking CTL and the Scalable Architecture, Terminology & Glossary, Documentation, Benchmarking, and Industry & Media Relations. In addition, a dedicated Task Force looks into the test issues of mergeable cores, such as the nonencrypted soft cores, which can be merged with other circuitry before the test method of choice is implemented. Status IEEE P1500 is currently in the development phase of the standard. The first version of the proposed standard focuses on non-merged digital logic and memory cores. It is planned to cover analog and mixed-signal cores, as well as the DfT guidelines for mergeable cores, in future extensions. The purpose of this paper is to provide a general view of the current direction of the standardization activity. Note that the technical solution presented is owned by the IEEE P1500 Working Group and that its presentation in this paper is an unapproved preliminary view on the standard. It is unapproved because it only reflects the interpretation of the authors of this paper and not the full IEEE P1500 Working Group. It is preliminary, because the standardization work is not finalized at this point of time.
Towards a Standard for Embedded Core Test: An Example
3 Dual Compliance Concept IEEE P1500 is based on a concept of two different levels of compliance.
‘IEEE 1500 Compliant Core’. This notion refers to a core that incorporates an IEEE 1500 wrapper function, and comes with an IEEE 1500 CTL program. The CTL program describes the core test knowledge, including how to operate the wrapper, at the wrapper’s external terminals.
‘IEEE 1500 Ready Core’. This notion refers to a core which does not have a complete IEEE 1500 wrapper, but does have a IEEE 1500 CTL program on the basis of which the core could be made ‘1500Compliant’, either manually or by using dedicated tools. The CTL program describes the core test knowledge at the bare core terminals. Note that at this time, the names of the two compliance levels have not been finalized yet, and that ‘1500-Ready’ and ‘1500Compliant’ are considered working names only.
The motivation behind the two different levels of compliance is that they provide the flexibility that is required in testing corebased system chips. The full benefits of test interoperability are only obtained from ‘1500-Compliant’ cores, and hence the ultimate goal should always be to make a core ‘1500-Compliant’. Nevertheless, the two levels of compliance provide the option to become ‘1500-Compliant’ directly, or via an intermediate stop at ‘1500-Ready’. The first alternative, i.e., direct generation of a ‘1500-Compliant’ core, provides the possibility to integrate the wrapper functionality with the core itself and hence minimize the performance and area impact of the wrapper. The second alternative is to first create a ‘1500-Ready’ core, which is then, in a second step, turned into a ‘1500-Compliant’ core. This enables to take advantage of the scalability of the standardized wrapper and instantiate the wrapper with particular parameter values, which take into account certain aspects of the system chip environment in which this particular core version is used. Below we list various use scenarios of the IEEE 1500 standard. They are only a few of the probably many interoperability scenarios that will be practiced once the standard is in place, and are meant here as an illustration of the flexibility provided by the dual compliance concept. Scenario 1 The core provider delivers a ‘1500-Ready’ core. The CTL program that comes with it contains all relevant core test knowledge. This also includes core-related data for generation of the IEEE 1500 wrapper, such as the number, names, and types of terminals of the core and which terminals are involved at which data rates in which core tests.
3
The core user makes the core ‘1500-Compliant’ by adding a wrapper to it and upgrading the CTL file from the core terminals to the wrapper terminals. He/she can take into account information specific to the particular system chip environment into which the core is integrated and which have impact on the wrapper, such as the number and width of the TAMs that will connect to the wrapper, the necessity of certain optional wrapper instructions, the ‘safe’ wrapper output values in case the corresponding wrapper instructions are implemented, etc. The benefit of the ‘1500-Ready’ predicate of the core provider’s product is that it guarantees the core user that all core-related test data is present and, while the wrapper is still adaptable to the specific chip environment needs, the route to a ‘1500-Compliant’ core is reliable and fast. We expect that, once the IEEE 1500 standard is in place, various ‘1500 Ready-to-Compliant’ tools that automate this trajectory will come into existence, making this route even faster. Scenario 2 The core provider delivers a ‘1500-Compliant’ core, which includes a wrapper built-to-order on the basis of parameters provided by customer specification. This scenario is very similar to Scenario 1; the main difference is that the work of converting a ‘1500-Ready’ core into a ‘1500-Compliant’ one is now carried out by the core provider instead of the core user. Core provider and core user must anyway cooperatively exchange information relating to core functionality, implementation, usage, and test. Hence, often it will not be a problem to take the customer specifications regarding the wrapper parameters into this discussion as well. The core provider might have experts with special tools, for whom transforming a ‘1500-Ready’ core into a customer-specified ‘1500-Compliant’ core is daily business. Scenario 3 The core provider offers a catalogue of off-the-shelf ‘1500Compliant’ cores with fixed wrapper parameters. The core user then selects from that catalogue the core which best matches the system chip needs. The core provider’s internal process how to get to ‘1500-Compliant’ cores is actually not relevant to the core user. However, this scenario allows the core provider to integrate the design of the wrapper with that of the core, in order to minimize silicon area and/or performance impact. Hence, it seems likely that this scenario will be popular for cores with strict requirements in those domains. Obviously, a larger catalogue w.r.t. different wrapper parameters will imply more work for the core provider. On the other hand, it provides freedom of choice to the customers and that might be a distinguishing feature.
4 Scalable Hardware Architecture In [7], a generic access architecture for testing embedded cores was introduced. This architecture is depicted schematically in Figure 1. It consists of the following elements: an (off- or on-chip)
Marinissen, Zorian, Kapur, Taylor, and Whetsel
4
source that generates test stimuli, a similar sink that evaluates the test responses, test access mechanisms (TAMs) that transport the stimuli from source to core and from core to sink, and a wrapper that, amongst other things, connects the TAMs to the core. From these elements, IEEE P1500 only standardizes the wrapper [13], and leaves the design of source, sink, and TAM up to the system chip designer. This wrapper, although standardized, is quite flexible, as it has to be able to wrap all kinds of cores with potentially different test access requirements, as well as connect to different numbers and types of TAMs.
UART
ROM wrapper
32-bit RISC CPU source
CUT
SRAM
tests, the wrapper also provides optional modes similar to the preload and clamp instructions as known from the IEEE 1149.1 (‘JTAG’) standard [14]. Wrapper Contents The wrapper itself contains the following elements.
A Wrapper Instruction Register (WIR). The WIR controls the operation of the wrapper. It is a shift/update register, similar to JTAG’s instruction register. The WIR operation is controlled from a few direct control inputs to the WIR.
Multiple wrapper cells. Wrapper cells provide controllability and observability on core terminals. In principle there is one wrapper cell per core terminal, although some core terminals do not have a wrapper cell associated with them. In the various wrapper modes, the wrapper cells are configured into one or multiple test access chains, through which stimuli can be applied and/or responses can be observed. There are multiple types of wrapper cells, e.g., depending on the direction of core terminals, such as input, output, and bidirectional. Also, the wrapper cells may be designed with or without ripple-while-shift properties.
A one-bit bypass register, similar to JTAG’s bypass register, which serves as a bypass for the serial TAM.
Wires to connect the various elements and multiplexers to select the various wrapper modes.
Timer TAM
sink
TAM
DRAM MPEG
UDL
SOC Figure 1: Generic test access architecture for embedded cores, consisting of source and sink, TAMs, and wrapper.
Wrapper Functions The P1500 wrapper is a thin shell around the core that provides the switching capability between the core and its various access mechanisms. In addition to a mode for connecting core inputs and outputs for functional operation, the wrapper has modes for connecting the core input and output terminals to (1) a mandatory 1-bit wide serial TAM, and (2) zero or more scalable parallel TAMs. Scalable means here that the width of the TAM is an integer, user-defined upon instantiation of the wrapper. The serial and (if present) parallel TAMs provide the required access for the core-internal tests which are described in the CTL program that comes with the core, as well as for core-external tests, that test the circuitry exterior to the core. For the coreinternal tests, controllability is provided from the TAM outputs connected at the wrapper boundary to the appropriate core input terminals, and likewise, observability is provided from the appropriate core output terminals to the TAM inputs connected at the wrapper boundary. For core-external tests, controllability is provided from the TAM outputs connected at the wrapper boundary to the wrapper’s functional outputs, and observability is provided from the wrapper’s functional inputs to the TAM inputs connected at the wrapper boundary. In the general case, the number of TAM outputs does not have to be equal to the number of core test inputs, and likewise for TAM inputs and core outputs. In such cases, the wrapper may provide width adaptation through serial-parallel and parallel-serial conversion. Next to the access provisions for core-internal and core-external
Internal and External Wrapper Interfaces At the internal wrapper interface, i.e., the wrapper-to-core interface, we distinguish the following signals. 1. Functional inputs and outputs. 2. Test data inputs and outputs, such as inputs and outputs of core-internal scan chains. 3. Dynamic test control inputs, such as scan-enable signals. 4. Static test control inputs, such as BIST-enable signals. 5. ‘Special care’ signals, i.e., non-digital and/or nonsynchronous signals, such as clocks and analog signals. Due to multiplexing of different signals at the core boundary, some of these categories might have non-empty intersections. An example of this is a functional input, which is reused during scan operation as scan chain input. At the external wrapper interface, i.e., the wrapper-to-chip interface, we distinguish the following signals. (N.B. If signals names are provided, this means that IEEE P1500 intends to standardize their name and function. Note however that those names and functions have not been finalized yet.)
Towards a Standard for Embedded Core Test: An Example
1. Functional inputs and outputs, which correspond to the functional inputs and outputs at the core boundary. 2. WIR control inputs wc[0..5], which determine the operation mode of the WIR. 3. Serial test interface si and so, used (1) to shift instructions in and out of the WIR, and (2) as interface to the serial TAM. 4. Zero or more parallel TAM interfaces pi and po. Their number and individual widths are scalable in the standard’s definition, but fixed upon instantiation of a specific wrapper.
5
the intention of IEEE P1500 to specify three categories of instructions: (1) mandatory instructions, which, in order to be ‘1500Compliant’, have to be implemented and result in prescribed behavior, (2) optional instructions, which, if implemented, should result in prescribed behavior in order to be ‘1500-Compliant’, and (3) user-defined instructions, for which no restrictions hold. Below we list a set of instructions which are currently under consideration by the IEEE P1500 Working Group. Note that number, names, and behavior of these instructions is still subject to modification.
Normal instruction, by which the wrapper is transparent, meant for normal (i.e., non-test) operation.
Instructions pertaining to the serial TAM. – Serial Internal Test instruction, by which core-internal tests can be applied via si and so. – Serial External Test instruction, by which coreexternal tests can be applied via si and so. – Serial Bypass instruction, by which the one-bit bypass register is selected between si and so. – Optional Serial Fixed Preload instruction, by which wrapper cells are connected between si and so, while their outputs are forced to (‘safe’) values, predetermined upon wrapper instantiation. – Optional Serial Programmable Preload instruction, by which wrapper cells are connected between si and so, such that, without interfering with the normal operation of the core, in a subsequent operation the states of the wrapper cells can be programmed to user-definable (‘safe’) values.
Modes pertaining to a parallel TAM, if present. (N.B. In the case of multiple parallel TAMs, these instructions are repeated per parallel TAM.) – Parallel Internal Test instruction, in which coreinternal tests can be applied via pi and po. – Parallel External Test instruction, in which coreexternal tests can be applied via pi and po. – Optional Parallel Fixed Preload instruction, in which wrapper cells are connected between pi and po, while their outputs are forced to (‘safe’) values, predetermined upon wrapper instantiation. – Optional Parallel Programmable Preload instruction, in which wrapper cells are connected between pi and po, such that, without interfering with the normal operation of the core, in a subsequent operation the states of the wrapper cells can be programmed to userdefinable (‘safe’) values.
Optional Clamp instruction, by which wrapper cells retain their current values, and the bypass register is selected between si and so.
5. Dynamic test control inputs for core and/or wrapper. 6. ‘Special care’ signals, which correspond to the ‘special care’ signals at the core boundary and are just fed through the wrapper without intervention.
functional inputs
functional outputs
Core functional I/O
pi (parallel TAM)
po (parallel TAM)
test data I/O dyn. test control static test control
dynamic test control
special care
special care
serial TAM
Bypass
si
special care
serial TAM
so
WIR
Wrapper wc[0:5]
SOC Figure 2:
Internal and external wrapper interfaces.
Figure 2 schematically shows the internal and external wrapper interfaces. Table 1 provides an overview of the external wrapper interface, the function of the various signals, their bandwidth, and their chip-level connection. Signal Type functional wc si/so pi/po-1 pi/po-2 ... pi/po-k dyn. test control special care
Function functional input/output WIR control (1) WIR programming + (2) serial TAM parallel TAM 1 parallel TAM 2 ... parallel TAM k dynamic test control analog, asynchronous
Table 1:
Width defined by core, (x,y) bits P1500 fixed, 6 bits P1500 fixed, 1 bit
Chip-Level user-defined broadcast concatenate
scalable, (n1 ,m1 ) bits scalable, (n2 ,m2 ) bits ... scalable, (nk ,mk ) bits defined by core + wrapper defined by core
user-defined user-defined ... user-defined user-defined to source/sink
External wrapper interface.
Instructions The mode of operation of the wrapper is determined by serially loading instructions into the Wrapper Instruction Register. It is
Marinissen, Zorian, Kapur, Taylor, and Whetsel
6
Instructions are loaded into the WIR by setting the WIR control inputs wc such that the WIR is willing to receive an instruction. This instruction is shifted in via the serial input si. While shifting in a new instruction, the previous instruction remains valid at the WIR outputs. Only after shifting in the complete instruction through wc the previous instruction is updated with the newly scanned in instruction. If no new instructions are loaded, the serial interface si/so doubles as interface to the serial TAM [13]. Typical Usage A typical situation we envision is that a wrapper is connected to one serial TAM and one multi-bit parallel TAM. The principal function of the parallel TAM is to test the core internally. Its actual width is chosen such that it meets the test requirements of the core, but also is not too expensive to the core integrator, e.g., with respect to silicon area and/or number of IC pins. Core-external tests might also be applied via the parallel TAM. The serial TAM is meant to support core-level test and debug. Once the system chip is used on a printed circuit board, the normal IC pins are not directly accessible, but test access can be provided via the serial TDI to TDO interface of a chip-level IEEE 1149.1 (‘JTAG’) port [14]. Furthermore the serial TAM can also be utilized to perform the core-external (‘interconnect’) tests or even core-internal tests. However, in the latter case, depending on the actual core-internal tests, it might be that the serial TAM does not provide sufficient bandwidth to perform these tests in a timely and at-speed manner. Figure 3 shows how the chip-level connections of the ‘1500Compliant’ cores might be connected in the abovementioned typical case of one serial TAM and one parallel TAM per core. The actual nature and implementation of the TAM is outside the scope of IEEE P1500, but user-defined, and hence not specified in this figure. For example, it could be the test bus [15], TestRail [16], or addressable test port mechanism [17], as proposed in recent papers, or any other TAM that one might invent.
from Source
po
funct. input
Core 1
...
so
si WIR
funct. input
...
Core N
si
User-Defined Test Controller
Aspects of the test data. – Raw characteristics, such as type of data, rate of data, stability of values.
funct. output
so
Different configurations of the core. – Test mode information. – Connectivity information as attributes and protocols. System integration instructions. – Connectivity information.
WIR
serial TAM
System Chip Figure 3:
wc
serial TAM
CTL describes three types of information.
po
P1500 Wrapper
funct. output
P1500’s CTL and IEEE 1450 STIL P1500’s CTL is defined using the syntax of IEEE 1450, the Standard Test Interface Language (STIL) [10, 11]. STIL has been developed as a common, standardized language for transferring digital test data from its generation environment, the EDA domain, to its application environment, the test equipment domain. Hence, STIL is capable of describing the test-related data, such as test patterns and waveforms, for ICs. Currently, the IEEE 1450 standards development committee is extending its standard in various directions [19]. One of those directions is the extension towards embedded cores. This particular extension is a shared effort between IEEE 1450 and IEEE P1500. P1500 uses as much as possible STIL as is, but adds two elements to STIL. Where necessary, new key words are created to augment STIL to describe test aspects specific for cores and the P1500 wrapper. Futhermore, a test information model is created that allows for defining the various configurations of the core that are needed to make a core ‘1500Ready’ or ‘1500-Compliant’.
– Test methodology related information.
pi
P1500 Wrapper
IEEE P1500’s Core Test Language (CTL) is a language for capturing and expressing test-related information for reusable cores [18]. CTL is meant to coexist with and complement existing structure-oriented means of representing test and testability attributes of a design entity. In particular, CTL attempts to provide an explicit, concise, and universal information model for corespecific controls to configure the core for testing itself and its surrounding chip functions, as well as provide requirements and constraints on the implementation of chip-level test interfaces for the core.
to Sink
User-Defined Parallel TAM pi
5 Core Test Language
Overview of the P1500 scalable architecture.
With the CTL program one can create enough information at the boundary of the core to allow for successful (1) instantiation of a wrapper, (2) mapping of the core terminals to wrapper terminals, (3) reuse of the core test data, and (4) testing of the user-defined logic and wiring external to the core. CTL Functions This section describes the functionality that is provided in the CTL
Towards a Standard for Embedded Core Test: An Example
data. The example code in Section 6 demonstrates these capabilities through a simplified example. 1. CTL is used to describe the internal characteristics of the core signals. This information is provided to allow the core integrator to know what is happening with each signal of the core without needing full access to the design information. Examples of this information are: wrapper type, timing accuracy required, electrical characteristics such as analog or digital, test data volume, and more. 2. CTL is used to describe the external characteristics that are expected from the perspective of the core boundary. Examples are: connect to chip pins (input, output, bidirectional), connect to another named core, connect to TAM, connect to user-defined logic, and more. 3. CTL defines the protocol for applying functional and/or scan test patterns to the core terminals. This protocol includes any enabling control or clocking signals, and the waveforms for those signals. 4. CTL defines the set of functional patterns and/or scan test patterns in a generalized form, using macros, such that they can be applied to the core via the wrapper and TAM. 5. CTL defines the purpose of each of the test patterns provided and the test mode necessary for the execution of each pattern. CTL Content CTL relies heavily on standard STIL structures for much of the pattern data. Certain structures have additional statements that convey the CTL information. The STIL/CTL blocks used are the following. 1. Signals. This block defines each of the signal names of the bare core along with the internal and external characteristics of each signal.
7
5. Timing. Each parallel or scan vector in a pattern macro has an associated timing block to define the waveshape and waveshape timing on each signal.
6. PatternBurst. This is a collection of patterns that are to be executed on the core. The patterns contain information as to the purpose of each pattern (normal functional, scan, IDDQ , BIST, other). Information is also contained to indicate any required sequencing of the patterns and which patterns may be run independently.
7. Pattern. The pattern blocks themselves contain the parallel and scan data for testing the core.
Specifying Wrapper Functions Table 2 provides an overview of the external wrapper interface functions as defined for each of the core signals. Signal Type functional WC si/so pi/po-1 pi/po-2 ... pi/po-k dyn. test control special care Table 2:
Function functional input/output WIR control (1) WIR programming + (2) serial TAM parallel TAM 1 parallel TAM 2 ... parallel TAM k dynamic test control analog, asynchronous
CTL UDL TestControl TAM TAM (group) TAM (group) ... TAM (group) TestControl PIN
CTL connect statements for the external interface.
Re-Use of CTL Patterns One of the most important requirements of the CTL language is that the patterns, which contain the bulk of the data, are re-usable without any modification whatsoever. This is accomplished by creating the patterns by using macro statements (M statements) as opposed to vector statements (V statements) [11]. This allows the vector application protocol to be modified by the core integrator in an expeditious manner.
2. CoreSignals. This block is essentially the same thing as the Signals block described above. It is used to retain the core-level signals after a wrapper is added and these core signals themselves are no longer directly accessible.
Each pattern is identified as to its intended purpose and required test mode, so that a test synthesis tool can select and re-order as desired, again, without actually having to adjust the bulk pattern data.
3. SignalGroups. This block defines useful combinations of signals that will be referenced throughout the rest of the pattern and timing blocks.
CTL is both human- and computer-readable, as is STIL. Hence, it can be utilized for documentation purposes, as well as for driving chip test integration tools. Among the tools which might be built using CTL are wrapper generation tools, 1500-Compliance checkers, chip-level test access planning and synthesis tools [15], test expansion tools that automatically translate a core-level test into an IC-level test [20], test scheduling tools [20], etc. The hope and expectation is that once the IEEE 1500 standard, and hence CTL, is in place, this will accelerate the development of such tools.
4. MacroDefs. This block contains the protocol for applying the test pattern data to the core or chip. A core-level test protocol defines the core’s test requirements to the core user. Once integrated, this protocol is expanded to chip level.
Marinissen, Zorian, Kapur, Taylor, and Whetsel
8
6 Example This section features a running example, which starts as a ‘bare’ core, and is subsequently made ‘1500-Ready’ and ‘1500Compliant’. The core in question is really a ‘toy example’, not at all representative of the complexity of today’s cores. However, we have selected this simplified example because of its educational value. In all its simplicity, it shows a large number of relevant aspects of the IEEE P1500 standard-under-development. We hope and trust that our readers will be able to extend this small example to their large and complex real-life cores.
6.1 Bare Core Our example core A is a scan-testable core with two core-internal scan chains. Scan chain 0 has a length of six flip flops and runs between terminals si[0] to so[0]. Scan chain 1 has length eight and runs between terminals si[1] to so[1]. The scan chains are shifting if terminal sc is asserted to logic value ‘1’. Furthermore, the core has five other input terminals, called d[0] d[4], and three other output terminals, called q[0] q[2]. Finally, core A has one clock input, called clk, which clocks all core-internal circuitry, including the scan chains. Core A is depicted in Figure 4.
si[0:1]
scan chain 0
(6 FFs)
scan chain 1
(8 FFs)
so[0:1]
core A d[0:4]
panying our example, focusses only on a subset of all that can be described in CTL, viz. the representation of test patterns for core-internal testing, their application protocol, and the instructions that prescribe how to integrate the core in a system chip such that its tests can be applied. Figure 6 contains the CTL program for core A, while Figure 5 shows pat1.stil, containing the test pattern data for core A. Together they form the CTL code that makes core A ‘1500Ready’. The pattern data is split off from the main program into a separate file, because it will be reused in the subsequent section of this paper by the CTL program for the ‘1500-Compliant’ core (see Figure 9). The test patterns in file pat1.stil contain the raw patterns, i.e., the 0’s and 1’s to be applied to and observed at the core terminals. The pattern file contains five test patterns, which are applied in such a way that scanning out the responses of one pattern is combined with scanning in the stimuli of the next pattern. At which core terminals and time slots these patterns are to be applied, is defined in a corresponding test protocol in the MacroDefs section of the main CTL program. Two macros are defined, viz. setup intest and do intest. The first macro configures the core in a way that the patterns can be applied to the core terminals, the second defines the actual application of test patterns. The macros refer to signals of the bare core defined in the Signals and SignalGroups sections of CTL. The patterns and macros fit in a framework defined by PatternExec and PatternBurst. The InTest pattern sets pat1, pat2, and pat3 are for the purpose of production testing of the chip and there is no particular order defined for their execution. To save space, pat2 and pat3 are not specified in the example.
q[0:2]
sc clk Figure 4: Example core A.
Core A has a set of predefined scan test patterns, which all adhere to the following protocol. Both scan chains are loaded with stimuli, after which the stimuli in the scan chains, as well as additional stimuli on inputs d[0..4] are applied. Subsequently, responses on q[0..2] are observed, and additional responses in the two scan chains are shifted out. In our particular example, the test patterns are deterministic, but these could just as well have been pseudo-random patterns.
6.2 ‘1500-Ready’ Core A ‘1500-Ready’ core comes with a CTL program containing the information as described in Section 5. The CTL program accom-
CTL 0.1; Header { Title "pat1.stil: Shared CTL Pattern Data"; Date "Fri June 25 1999"; } Pattern pat1 { // setup do_intest mode in WIR M setup_intest {} // bulk of pattern data follows M do_intest { d=00000; si0=111000; si1=11110000; } M do_intest { so0=LLHXHH; so1=HHHHLLXH; q=LLH; d=01101; si0=011010; si1=01011101; } M do_intest { so0=HHLLXH; so1=HLHHLLLL; q=HHL; d=11001; si0=110010; si1=00011100; } M do_intest { so0=LHLLLH; so1=HXHHLHLL; q=LLX; d=01010; si0=001101; si1=10011101; } M do_intest { so0=HHXLLL; so1=HLHHHLXX; q=LHH; d=01111; si0=010001; si1=10101101; } M do_intest { so0=LXHHHH; so1=LLLLHXHL; q=LLL; } }
Figure 5:
pat1.stil, containing the CTL-coded test patterns for core A.
Towards a Standard for Embedded Core Test: An Example
9
CTL 0.1; Header { Title "CTL Program for 1500-Ready Core"; Date "Fri June 25 1999"; } Signals { d[0..4] In { CoreExternal { ConnectTo UDL; }} q[0..2] Out { CoreExternal { ConnectTo UDL; }} si0 In { ScanIn 6; CoreExternal { ConnectTo TAM; }} si1 In { ScanIn 8; CoreExternal { ConnectTo TAM; }} so0 Out { ScanOut 6; CoreExternal { ConnectTo TAM; }} so1 Out { ScanOut 8; CoreExternal { ConnectTo TAM; }} sc In { CoreExternal { ConnectTo PIN; }} clk In { CoreExternal { ConnectTo PIN; }} } SignalGroups { d = ’d[0..4]’; q = ’q[0..2]’; ins = ’d+si0+si1+sc+clk’; outs = ’q+so0+so1’; all = ’ins+outs’; } Timing normal { // waveform and timing information omitted WaveformTable scan_timing { } WaveformTable func_timing { } } MacroDefs { setup_intest { C { all=xxxxx xx 00 xxx xx; } } do_intest { // perform scan W scan_timing; C { ins=xxxxx 00 11; outs=xxxx xx; } Shift { V {si0=#; si1=#; so0=#; so1=#; }} // perform normal cycle W func_timing; C { sc=0; } V { d=#; q=#; } } } PatternExec run_all { Purpose production; Timing normal; Category normal; PatternBurst all_pats; } PatternBurst all_pats { TestMode InTest; PatternSet { pat1; pat2; pat3; } } Include "pat1.stil";
Figure 6:
CTL code for the ‘1500-Ready’ core A.
The macros contain four different types of statements [11]. All statements are incremental, i.e., their data encodes only the differences relative to previous statements.
WaveformTable statement W, defining the timing information. Vector statement V, defining broadside stimuli and responses to be applied. For the actual values of stimuli and responses is referred to pat1.stil.
Scan test statement Shift, defining scan chain stimuli and responses to be applied. For their actual values is again referred to pat1.stil. Condition statement C, which defines the default background value of terminals, to be used and possibly overruled in the V statements that follow. Fixed statement F, which defines fixed values of terminals, which cannot be overruled by later statements (this statement is only used in Section 6.3).
Most of the CTL code in this example is actually standard STIL [11]. An example of newly added CTL constructs, i.e., constructs which did previously not exist in standard STIL, are the ConnectTo attributes in the Signals section of Figure 6. These attributes reflect system integration instructions for the ‘1500-Compliant’ core. When the attribute ConnectTo is embedded in a CoreExternal statement, it describes a connection to be done by the system integrator. On the other hand, when this attribute is embedded in a CoreInternal statement it is describing already existing connections internal to the core. In our example, these attributes in the Signals section of the CTL program specify that d[0..4] and q[0..2] should be connected to functional circuitry, the scan chain inputs and outputs are to be connected to TAMs, and sc and clk are ‘special care’ signals that require a direct connection to an IC pin.
6.3 ‘1500-Compliant’ Core In order to make core A ‘1500-Compliant’, a wrapper is instantiated and added to the core, and a CTL program is created that describes the core’s test(s) at the wrapper boundary. In this section we describe both. ‘1500-Compliance’ can be reached either directly from the bare core, or via an intermediate stop at ‘1500Ready’, as described in Section 3. Core plus wrapper are depicted in Figure 7. Note that, whereas this figure shows some implementation details, IEEE P1500 only defines the behavior of the wrapper and leaves the implementation free. In this particular example, the wrapper can connect core A both to a serial TAM, via si and so, as well as to a 3-bit wide parallel TAM, via pi[0:2] and po[0:2]. Upon wrapper instantiation, it was decided not to implement the optional preload and clamp instructions for this particular wrapper. The example wrapper provides six instructions, supporting normal mode, and connections to both serial and parallel TAM. Mode setting through the WIR actually means setting the controls of the wrapper’s multiplexers. In Figure 7a, the multiplexers that do occur in the wrapper are named m1, m2, : : :, m6. Figures 7b and 7c show additional multiplexers wci and wco in the wrapper input and output cells, respectively. Table 3 lists the six WIR instructions and the corresponding multiplexer settings they cause. Figure 8 depicts the wrapper in each of its six modes by bold highlighting of the active wires in a particular mode.
sc
wci
Marinissen, Zorian, Kapur, Taylor, and Whetsel
10
from chip m3 m2
pi[0:2]
scan chain 0
(6 FFs)
scan chain 1
(8 FFs)
to core
scan-in
po[0:2]
FF
m4
scan-out
clk
core A
wrapper input cell
d[0:4] sc
sc
(b)
q[0:2]
q[0:2]
wco
d[0:4]
clk
m1
from core m5
clk sc
Bypass
m6
si
to chip
scan-in
Wrapper Instruction Register
FF
so
scan-out
clk
Wrapper wrapper output cell
wc[0:5]
(c)
(a)
Figure 7: Example core A plus its P1500 wrapper (a) and the implementation of the wrapper input cell (b) and wrapper output cell (c).
(6 FFs)
scan chain 1
(8 FFs)
po[0:2] pi[0:2]
scan chain 0
(6 FFs)
scan chain 1
(8 FFs)
m4
d[0:4] clk
sc
po[0:2] pi[0:2]
scan chain 0
(6 FFs)
scan chain 1
(8 FFs)
d[0:4]
(8 FFs)
d[0:4]
sc
sc
so
wc[0:5]
(e) Serial External Test Mode Figure 8:
Wrapper Instruction Register
so
Wrapper
wc[0:5]
(d) Serial Internal Test mode
si
m6
m6
m6
Wrapper Instruction Register
Wrapper
Bypass
m5
Bypass
si
clk
m1
clk sc
m5
m5
so
Wrapper
q[0:2]
q[0:2]
clk
m1
clk sc
po[0:2]
d[0:4]
q[0:2]
q[0:2]
m1
Wrapper Instruction Register
(6 FFs)
scan chain 1
core A
d[0:4]
q[0:2]
clk
Bypass
scan chain 0
m4
core A
q[0:2]
si
po[0:2] pi[0:2] m4
d[0:4]
m6
(8 FFs)
(c) Parallel External Test Mode
m3 m2
(6 FFs)
scan chain 1
m3 m2
m3 m2
scan chain 0
so
wc[0:5]
(b) Parallel Internal Test mode
core A
clk sc
Wrapper Instruction Register
Wrapper
m4
sc
Bypass
si
wc[0:5]
(a) Normal mode
d[0:4]
so
Wrapper
wc[0:5]
pi[0:2]
m6
Wrapper
Wrapper Instruction Register
m5
Bypass
si
clk
clk sc
m5
so
q[0:2]
q[0:2] sc m1
clk sc m6
Wrapper Instruction Register
po[0:2]
d[0:4]
clk
m1
m5
si
d[0:4] q[0:2]
q[0:2]
m1
Bypass
(8 FFs)
core A
d[0:4]
q[0:2]
q[0:2]
clk sc
(6 FFs)
scan chain 1
m4
core A
d[0:4]
sc
scan chain 0
m4
core A d[0:4]
po[0:2] pi[0:2]
m3 m2
scan chain 0
m3 m2
m3 m2
pi[0:2]
The wrapper in action in its various modes.
wc[0:5]
(f) Serial Bypass mode
Towards a Standard for Embedded Core Test: An Example Wrapper Instructions Normal Mode Parallel Internal Test Parallel External Test Serial Internal Test Serial External Test Serial Bypass
wci 0 1 0 1 0 X
11
wco 0 0 1 0 1 X
Multiplexer Settings m1 m2 m3 m4 X X X X 0 0 0 1 0 X X 1 1 1 1 0 1 X X 1 X X X X
m5 X X X 0 0 1
m6 X X X 0 0 0
Table 3: Multiplexer settings for the various wrapper instructions.
CTL 0.1; Header { Title "CTL Program for 1500-Compliant Core"; Date "Fri June 25 1999"; } CoreSignals core_a_bare_signals { // original core signal definition is maintained d[0..4] In { CoreExternal { ConnectTo UDL; }} q[0..2] Out { CoreExternal { ConnectTo UDL; }} si0 In { ScanIn 6; CoreExternal { ConnectTo TAM; }} si1 In { ScanIn 8; CoreExternal { ConnectTo TAM; }} so0 Out { ScanOut 6; CoreExternal { ConnectTo TAM; }} so1 Out { ScanOut 8; CoreExternal { ConnectTo TAM; }} sc In { CoreExternal { ConnectTo PIN; }} clk In { CoreExternal { ConnectTo PIN; }} } Signals { // New Signals block for the wrapped core si In { CoreExternal { ConnectTo TAM; } } sc In { CoreExternal { ConnectTo PIN; } } clk In { CoreInternal { DriveAccuracy Critical; } CoreExternal { ConnectTo PIN; DataType Clock; } } d[0..4] In { CoreInternal { ConnectIn Scan m1m4 ’0..4’; Wrapper IEEE-1500; } CoreExternal { ConnectTo UDL; } } pi[0..2] In { CoreExternal { ConnectTo TAM; } } po[0..2] Out { CoreExternal { ConnectTo TAM; } } q[0..2] Out { CoreInternal { ConnectOut Scan m1m4 ’5..7’; Wrapper IEEE-1500; } CoreExternal { ConnectTo UDL; } } so Out { CoreExternal { ConnectTo TAM; } } wc[0..5] In {
Figure 9:
CoreInternal { DriveAccuracy NonCritical; } CoreExternal { ConnectTo PIN; DataType TestControl; } } } SignalGroups { si_m123 = ’si’ { ScanIn 22; } // length of (d+ch0+ch1+q) si_wir = ’si’ { ScanIn 6; } so_m123 = ’so’ { ScanOut 22; } wc = ’wc[0..5]’; } Timing normal { // waveform and timing details omitted WaveformTable setup_timing { } WaveformTable do_intest_timing { } } MacroDefs { setup_intest { Purpose Instruction; W setup_timing; // setup default conditions on all signals used C { si=0; so=X; wc=000000; } // put WIR in receive mode V { wc[0..4]=10000; } // shift instruction into WIR Shift { V{si_wir=111000; wc[5]=1;} } // put WIR in update mode; instruction in effect F { wc=010001; } } do_intest { Purpose ControlObserve; W do_intest_timing; C { si_m123=0; so_m123=X; clk=1; sc=1;} Shift { V{si_m123=’d, si1, si0’; so_m123=’so1, so0, q’;} } V { clk=1; sc=0; } } } PatternExec run_all { Purpose production; Timing normal; Category normal; PatternBurst all_pats; } PatternBurst all_pats { TestMode InTest; PatternSet { pat1; pat2; pat3; } } Include "pat1.stil";
CTL code for the ‘1500-Compliant’ core A.
Marinissen, Zorian, Kapur, Taylor, and Whetsel
12 Figure 9 contains the CTL program for core A defined at its wrapper boundary. This ‘1500-Compliant’ CTL program contains the same information as the original ‘1500-Ready’ CTL program of Figure 6. Hence, while transitioning from ‘1500-Ready’ to ‘1500Compliant’, no information was lost. On top of that, additional information is present in the ‘1500-Compliant’ CTL code, containing the wrapper terminal names, the WIR instructions implemented, the modified test protocols at the wrapper boundary, and modified system integration instructions. In the CTL program provided as an example in this paper, we focus on the Serial Internal Test mode, as depicted in Figure 8d. The test patterns specified in the file pat1.stil (see Figure 5) remain intact and valid for core-internal testing of core A, and hence are again referenced from our CTL program. However, their application protocol at the wrapper boundary has changed. The setup for InTest requires that the Serial Internal Test instruction is scanned into the shift register of the WIR and subsequently loaded into its update register. The changes in macro do intest reflect the extra steps needed to move the test pattern data from the serial TAM output connect to si through the wrapper to the core, and vice versa back out again via so to the serial TAM input. Section CoreSignals is a new CTL construction, currently not existing in standard STIL [11]. For archival purposes it lists the connectivity requirements of the, now wrapped, bare core. The new connectivity requirements of the wrapped core are passed on to the Signals section of the CTL program.
References [1] Rajesh K. Gupta and Yervant Zorian. Introducing Core-Based System Design. IEEE Design & Test of Computers, 14(4):15–25, December 1997. [2] Thomas Anderson. This is Hard Core. Test - The European Test Industry Journal, Vol. 25(No. 5):S–5–6, June 1999. [3] Yervant Zorian, Erik Jan Marinissen, and Sujit Dey. Testing EmbeddedCore-Based System Chips. IEEE Computer, 32(6):52–60, June 1999. [4] Erik Jan Marinissen and Yervant Zorian. Challenges in Testing Core-Based System ICs. IEEE Communications Magazine, 37(6):104–109, June 1999. [5] Lee Whetsel. Core Test Connectivity, Communication, & Control. In Proceedings IEEE International Test Conference (ITC), pages 303–312, Washington, DC, October 1998. IEEE Computer Society Press. [6] Yervant Zorian. Testing the Monster Chip. IEEE Spectrum, 36(7):54–60, July 1999. [7] Yervant Zorian, Erik Jan Marinissen, and Sujit Dey. Testing Embedded-Core Based System Chips. In Proceedings IEEE International Test Conference (ITC), pages 130–143, Washington, DC, October 1998. IEEE Computer Society Press. [8] Yervant Zorian. Test Requirements for Embedded Core-Based Systems and IEEE P1500. In Proceedings IEEE International Test Conference (ITC), pages 191–199, Washington, DC, November 1997. IEEE Computer Society Press. [9] IEEE P1500 Web Site. http://grouper.ieee.org/groups/1500/. [10] Tony Taylor and Gregory Maston. Standard Test Interface Language (STIL): A New Language for Patterns and Waveforms. In Proceedings IEEE International Test Conference (ITC), pages 565–570, Washington, DC, November 1996. IEEE Computer Society Press. [11] Gregory Maston, Tony Taylor, et al. Standard Test Interface Language (STIL) for Digital Test Vector Data - Language Manual, D.095 edition, January 1999. [12] IEEE 1450 Web Site. http://grouper.ieee.org/groups/1450/.
7 Conclusion The package that a core provider delivers to the core user needs to include, among others, a test-related element. This test element can either solely contain the test knowledge of the given core, or it may also include a hardware core test access function. In either case, IEEE P1500 SECT eases the test interoperability between the core provider and core user by standardizing the test-related elements. In the first case, the core meets the requirements of an ‘IEEE 1500 Ready Core’, i.e., a CTL program is included in the delivery package. And in the second case, an ‘IEEE 1500 Compliant Core’ is delivered with its embedded test access function and CTL program. A simplified example core, described in this paper, illustrates both of these cases and aims at providing an early introduction to the basic aspects of the IEEE P1500 standard-underdevelopment.
Acknowledgements We thank our fellow members of the IEEE P1500 Standard for Embedded Core Test (SECT) Working Group for co-developing the standard with us and we look forward to our continued cooperation with them in the future. Furthermore, we wish to thank our respective employers, who allow us to work in this exciting field towards a standard from which the entire semiconductor industry should benefit.
[13] Saman Adham et al. Preliminary Outline of IEEE P1500 Scalable Architecture for Testing Embedded Cores. In Proceedings IEEE VLSI Test Symposium (VTS), pages 483–488, Dana Point, CA, April 1999. IEEE Computer Society Press. [14] IEEE Computer Society. IEEE Standard Test Access Port and BoundaryScan Architecture - IEEE Std. 1149.1-1990. IEEE, New York, 1990. [15] Prab Varma and Sandeep Bhatia. A Structured Test Re-Use Methodology for Core-Based System Chips. In Proceedings IEEE International Test Conference (ITC), pages 294–302, Washington, DC, October 1998. IEEE Computer Society Press. [16] Erik Jan Marinissen, Robert Arendsen, Gerard Bos, Hans Dingemanse, Maurice Lousberg, and Clemens Wouters. A Structured And Scalable Mechanism for Test Access to Embedded Reusable Cores. In Proceedings IEEE International Test Conference (ITC), pages 284–293, Washington, DC, October 1998. IEEE Computer Society Press. [17] Lee Whetsel. Addressable Test Ports: An Approach to Testing Embedded Cores. In Proceedings IEEE International Test Conference (ITC), Atlantic City, NJ, September 1999. IEEE Computer Society Press. [18] Rohit Kapur et al. P1500-CTL: Towards a Standard Core Test Language. In Proceedings IEEE VLSI Test Symposium (VTS), pages 489–490, Dana Point, CA, April 1999. IEEE Computer Society Press. [19] Tony Taylor. Standard Test Interface Language (STIL), Extending the Standard. In Proceedings IEEE International Test Conference (ITC), pages 962– 970, Washington, DC, October 1998. IEEE Computer Society Press. [20] Erik Jan Marinissen and Maurice Lousberg. The Role of Test Protocols in Testing Embedded-Core-Based System ICs. In Proceedings IEEE European Test Workshop (ETW), Konstanz, Germany, May 1999. IEEE Computer Society Press.
