CAD DFT and Test rchitectures:Architectures for Systems-on-Chip

Architectures for Systems-on-Chip

Advances in integration technology allow the functionality of an entire system to be implemented on a single chip. Such systems-on-chip (SOCs) are composed of logic blocks knows as cores, in the same way that a system is made up of chips at the board level. The cores are provided to the system designer by independent vendors who retain their intellectual property (IP) rights. They can come either as hard (layout optimized), firm (optimized up to floorplanning), or soft (described at the register-transfer level). The testability problems of SOCs are similar to those in PCBs (see Section 68.2.1), but with the additional constraint that all logic is now integrated on a single chip.

Owing to the size and complexity as well as the IP restrictions, it is very difficult to apply standard ATPG mechanisms to ensure that the right test patterns are applied to each core from the SOC inputs and that the corresponding output responses are propagated to the SOC outputs. Instead, appropriate test access mechanisms (TAMs) must be implemented on the SOC to make each core controllable and observable, and logic (known as test wrapper) has to be added on and around each core to interface it to the SOC for testing purposes. A standard for this purpose is being developed (IEEE P1500) [4].

TAMs can be based on extra lines introduced on the SOC or on existing lines in the SOC or on combinations of these [5–12]. Extra lines provide in general lower testing times at the expense of hardware overhead.

Extra lines can be organized as test buses [10] or as test rails [8]. A test bus provides access to multiple cores along it. The cores share the bus by having their I/O pins tri-stated except for the core that is being tested at each time. A test control bus must also be provided on the SOC along with the logic (test controller) that controls it. In contrast, test rails are extra interconnects from one core to the next. Since the test rails on core inputs and the test rails on its outputs are separated by the application logic of the core (referred to as kernel), it is also convenient to have extra lines bypassing the kernel and connecting the core’s inputs and outputs directly (bypass mode). Any core that is not being tested can be in this bypass mode to aid the testing of another core by carrying through test data for it. Bypassing can also be accomplished by making a core transparent, i.e., by carrying unchanged values from the core inputs to the core outputs through the existing lines and logic of the core. Making a core transparent requires in general also some extra lines and multiplexing hardware since no transparency paths of sufficient width may exist through the core’s logic.

TAMs can also be implemented through existing SOC lines (core interconnects). In Ref. [13], existing SOC lines are used as much as possible to carry test values from the outputs of one core to the inputs of the next core linked to it, while extra lines are introduced for bypassing purposes, i.e., to carry though test values from the inputs to the outputs of the same core.

In conjunction with the TAM, the terminals of each core must be appropriately interfaced to it. This is achieved by logic around the core, known as core test wrapper. Examples of core test wrappers include the test collar [10], the test shell [8, 40], the InTeRail wrapper [13], and the isolation ring (a boundary scan-like structure).

The basic functions of a core test wrapper include: (1) normal mode, where the wrapper is configured to allow the original core interconnections for normal operation; (2) kernel test mode, where the wrapper is configured to allow the testing of the core kernel itself; (3) interconnect test mode, where the wrapper is configured to make the core output pins be controllable and the core input pins be observable; and (4) bypass mode, where the wrapper is configured to bypass the core kernel.

The test wrapper should also provide for width adaptation. That is, the TAM width may actually be smaller than the number of input or output terminals of a core. In that case, some of the core inputs and outputs must be configured as a small shift register that is driven by a single TAM line, while the wrapper does serial-to-parallel conversion for inputs and parallel-to-serial conversion for outputs. In addition, the wrapper may allow for dynamic reconfigurability [14]. That is, the wrapper may provide the SOC designer with the capability to customize the number and length of the above shift registers as well as the number and length of any internal scan chains that the core kernel is equipped with to achieve particular trade-offs between test time and TAM hardware overhead.

Design automation aspects in SOC design typically focus primarily on minimizing the SOC test time. Issues include the determination of optimal number of TAMs, partitioning the TAM width among cores, assignment of the cores to TAMs, determination of optimal wrapper designs for the cores, use of test compression, and concurrent testing of the cores. Algorithms for these purposes can be found in Refs. [13,15–17,20].

The problem of test scheduling for concurrent core testing is actually intertwined with the problem of test resource allocation (TAM lines, wrapper width). It can be formulated in its general form as follows: Let W be the total number of SOC pins and let N be the total number of cores in the SOC. Each core Ci , 1 <_ i <_ N, has wi pins to interface it (through the wrapper) to the rest of the SOC for testing purposes. Notice that the number of functional pins of the core may be larger than wi , but as mentioned above the wrapper provides for width adaptation when in testing mode. Each core Ci also has a testing time Ti associated with it, which depends on the available width wi (Ti is a nonincreasing function of wi). Additional values may be associated with a core Ci such as power consumption Pi for the application of the test set.

The objective in the test scheduling/resource allocation problem is to determine a quadruple (wi , Si , Ti , ti) for each core Ci , 1 <_ i <_ N, where wi is the number of test access pins of core Ci , Si the set of the specific SOC pins assigned to access Ci through the TAM (|Si| = wi), Ti the testing time corresponding to wi , and ti the scheduled starting time for the testing of Ci such that (1) Σwi <_ W, (2) max(Ti +ti) is minimized, (3) all cores being tested concurrently at any time instant have disjoint Si sets, and (4) all cores being tested concurrently at any time instant also satisfy a number of other (optional) constraints such as that the sum of their power consumptions Pi be less than a prescribed bound P, etc.

An algorithmic framework for solving the above problem is provided by the two-dimensional packing problem (also known as rectangle packing). Each core Ci is associated with a rectangle of length Ti (horizontal dimension) and width wi (vertical dimension). All cores have to be packed in a “bin” of width W and of minimum length (testing time), so that no rectangles overlap and all rectangles intersected by a vertical line satisfy the other (optional) constraints in (4) above. Algorithms for this purpose can be found in Refs. [15,16]. An alternative framework based on network flows can be found in Ref. [14]. Other approaches with restrictions of various degrees appear in Refs. [17–19], among others.