CC BY
78
ASIC DESIGN FLOW AND TEST GENERATION CAPABILITIES
RIMANTAS SEINA USKAS
Kaunas University of Technology. Lithuania; rsei@sc-uni.ktu.lt
Abstract. High-level test generation approaches require fault models adopted for high-level descriptions and adequate for testing defects or for the coverage of the stuck-at faults on the gate level. It is demonstrated that test generation on system-level model cannot guarantee the complete fault coverage on gate-level model for each possible implementation. The suggested ASIC design flow reduces time-to-market. The test supplement activities on gate-level and system-level models or both enable to reach the required fault coverage.
1. Introduction
In the standard ASIC design flow the designers mainly work on RT- (or higher) level descriptions. Nowadays logic synthesis tools automatically generate gate-level descriptions. However, most ofthe test activities (test structure insertion, test vector generation, fault coverage evaluation, etc,) are still performed on the gate-level netlists.
This situation has several drawbacks:
- the design testability is known only after the analysis of the gate-level netlist
- the design changes for testability have to be done back on the RT-level description
- re-synthesizing and re-validating increases design time and reduces quality
- test generation is performed on very large netlists which do not include high-level functional information
Several research efforts have been undertaken to devise test methods being able to work directly on high-level descriptions. However, there are some key questions that must be answered in order to develop industrially effective high-level test methodologies: What fault models should be adopted for high-level descriptions? Are these high-level fault models adequate for testing defects orfor the coverage ofthe stuck-atfaults on the gate level? The answer to the key questions determines the ASIC design flow.
2. Fault Models
Most of the high-level fault models for behavioral HDL descriptions were inspired by the current practice of software testing and extended to cope with hardware descriptions. In this sense, the high-level fault model corresponds to a metric that measures the goodness of a given sequence of input vectors. No single fault model is universally accepted, since no comprehensive and general results, valid for all classes of circuits, are known yet.
An abstraction is the main strength ofthe stuck-at fault model and the reason for its longevity. By staying away from the physical details the stuck-at fault model remains effective with changing technologies and design styles. The stuck-at fault model operates in the logic domain while most physical
level models operate in analog or even in the Electro-magnetic domain. With the rapidly growing number of transistors on a chip, abstraction is a necessity to manage complexity. The trend for the future is likely to be a higher level of abstraction.
Test vectors for the gate’s inputs and output stuck-at faults detect many defects internal to a primitive logic gate. If a defect internal to a CMOS simple gate is detectable by some Boolean test, then it is sufficient to have only test vectors that test the stuck-at faults on the gate terminals. For complex gates or blocks, such as XOR, MUX, ALU etc. it is true if the blocks are described in terms of primitive gates AND, OR and NOT [1].
The high-level fault models taken from software testing have three main advantages: they are well known and quite standardized; they require little calculations, apart from the complete fault-free simulation; and they are already embedded in some commercial tools. However, while such metrics may be useful to validate the correctness of a design, they are usually inadequate to foresee the gate-level fault coverage with high degree of accuracy. One of the most used fault models is the observability enhanced statement coverage metric proposed in [2] and [3 ]. This fault model requires that all statements in the VHDL description are executed at least once, and that their effects are propagated to at least one primary output. Observability-Enhanced statement coverage proposed in [4] uses explicit RT-level single-bit stuck-at’s. An RT-level singlebit stuck-at fault is defined as a single-bit stuck-at in the effect of an RT-level assignment operation. The signal or variable of an assignment statement loads the correct value, except for one bit that remains stuck-at to 0 or 1.
Some approaches rely on a direct examination of the HDL description [5] or exploit the knowledge of the gate-level implementation [6]. Some extract of the corresponding control machine from a behavioral description is used.
The listed approaches are of limited generality, have reduced integration into real design flows and the adequacy of testing defects or of the coverage stuck-at faults on the gate level are not proved.
3. The impact of circuit implementation on the test set
The functions of complex gates or blocks can be described (implemented) in terms ofprimitive gates AND, OR and NOT in different ways. The test set for each implementation of block functions can be different. The exhaustive test (2n) includes all possible test vectors of n inputs. The complete test detects all single stuck-at faults (ssf) of the block described in terms of primitive gates AND, OR and NOT.
Often, several implementations for a circuit are possible. These implementations differ in their area, delay and power requirements as well as in their test sets. We consider the impact of circuit implementation to the test set, which detects circuit defects
Assumption 1: The test set of the function F always includes the input vector v if this vector is an input vector of the function true table with one only output value 1 or 0. There is a special kind of function with the unique minterm, which corresponding test vector is necessary for function testing. We can make the following very powerful assertion.
Assertion 1. Each input vector v of the true table is necessary for testing at least one implementation of the function F.
74
R&I, 2003, Ns 3
Proof: Suppose an input vector v* is not necessary for testing the implementation ofthe functionF. We split the functionF into two functionsF1 andF2, where F=F1 v F2 ( ifF(v*)=1), F=F1 a F2 ( if F (v*)=0), F1 (v)=F (v) except that F1 (v*) = F (v*), F2 (v) = -, F (v*) except that F2 (v*) = F (v*), The implementation of the function F is shown in Figure 1. The functions F1 and F2 mustbe testedfor this implementation. Accordingto Assumption 1, the test set of the function F2 includes the input vector v* what is a contradiction to the presumption that the input vector v* is not necessary for testing.
We can make the following very important conclusion:
Conclusion: It is impossible to get a complete test set less than the exhaustive test without information about concrete implementation of the block
Figure 1. Implementation of the function F
Table 1
T F 3 F 4 T F 1 F 2 T F x1 x2 x3 xq F F 1 F 2 F 3 F 4
* 0 0 0 0 0 0 0 1 1
* * * 0 0 0 1 0 0 0 0 0
* * 0 0 1 0 0 0 0 0 0
* * * 0 0 1 1 1 1 0 1 0
* * 0 1 0 0 0 0 0 0 0
* 0 1 0 1 0 0 0 0 0
* 0 1 1 0 0 0 0 0 0
* 0 1 1 1 1 0 1 1 0
* * 1 0 0 0 0 0 0 0 0
1 0 0 1 0 0 0 0 0
* 1 0 1 0 0 0 0 0 0
1 0 1 1 1 1 0 1 0
* * * 1 1 0 0 1 1 0 1 0
1 1 0 1 1 1 0 1 0
* 1 1 1 0 1 1 0 1 0
1 1 1 1 1 1 0 1 0
Example. Let F= xj x2 + x3 x4 . In Table 1 all input vectors (xj x2 x3 x4) and output values of the function F are listed.
Figure 2 shows the implementationof example function. Vectors of the test set for sample function are marked with * in the column under TF. This test set does not include the input vector (xj x2 x3 x4) = 0111. We create a new implementation, which requires this input vector as a test vector. We split the function F into two functions F1 and F2, where F = F1 v F2. The output values of functions F1 and F2 are in the columns under F1 and F2. The function F1 differs from the functionF on the outputvalue for the input vector (xj x2 x3 x4)=0 1 1 1. Figure
Figure 2. Implementation of example function F.
The function F2 has one and only one positive output value for that input vector. The implementation by coupling functions F1and F2 is shown in Figure 4. Vectors of the test set for this implementation are marked with * in the column under TF1F2. We see that the input vector (xj x2 x3 x4) = 0111 is included into the test set of this implementation, which don’t have redundant and untestable stuck-at faults.
Figure 4. Implementation of the function F by coupling functions F1and F2
In the similar way we create an implementation, which requires input vector (xj x2 x3 x4) = 0000 as a test vector. We split the function F into two functions F3 and F4, where F = F3 a F4. The output values of functions F3 and F4 are shown in the columns under F3 and F4. The function F3 differs from the function F on the output value for the input vector (xj x2 x3 x4) = 0000. The function F4 has one and only one negative output value for that input vector. The implementation by coupling functions F3 and F4 is shown in Figure 5. Vectors ofthe test set for this implementation are marked with * in the column under TF3F4. We see that the input vector (xj x2 x3 x^) = 0000 is included into the test set of this implementation, which don’t have redundant and untestable stuck-at faults.
Figure 5. Implementation of the function F by coupling functions F3 and F4
R&I, 2003, N 3
75
4. ASIC Design Flow
A design before sending it to manufacturing needs a test program development. Verifying the test program involves running it on a working model of the
chip, which is only available later in the design process. Testers are very expensive and test verifying can load these machines for long periods of time. Starting test development at the end of the design process greatly prolongs the time-to-market. If a top-down design methodology is used, then a system-level model of the chip exists early in the design process. This system-level model can be used during the development of the test program. Thus, the test engineers can become involved with the project much earlier, and like the block designers, are given a working virtual prototype of the chip in the form of a system-level model. This improves communication between the test and design engineers, acts to greatly reduce the cost of development, allows the test program to be more thoroughly verified, permits the test programs to be developed concurrently with the chip, helps to insure that the test program is available a soon as the chip is ready to be manufactured. In addition, involving the test engineers while the design in ongoing allows fault simulation and design for test to be attempted.
The top-down design methodology is primarily based on the automatic (computer-aided) synthesis of the gate-level netlist, using a behavioral or system-level description. The synthesized logic is subsequently mapped onto a standardcell library. The top-down design methodology is well suited for purely digital designs with relatively short turn-around times and moderate area-performance requirements. Time-to-Market depends on the duration of the logic synthesis and on the duration of the design for test and test generation (see the top of Figure 6). The design for test and test generation on the system level-level model can reduce time-to-market. In any case fault coverage analysis on gate level model is necessary, but it is not time consuming task (Figure 6). The length of test sequences generated on system-level model can be compacted together with the fault coverage analysis. Therefore, the length of test sequences generated on system-level model is not a critical parameter. The flowchart presented in Figure 6 illustrates time-to-market dependency on design flow stages.
5. Conclusions
1. The design for test and test generation on system-level model reduces time-to-market
2 The length of test sequences generated on system-level model is not a critical parameter, because it can be easily reduced by fault coverage analysis on the gate-level model
3. Test generation on system-level model can not guarantee the complete fault coverage on gate-level model for each possible implementation
4. The suggested test supplement activities are necessary in the ASIC design flow
5. The test supplement activities on gate-level and system-level models or both enable to reach the required fault coverage.
6. Test generation on system-level model is preferable if the efforts and duration of test supplement activities are less than the efforts and duration of test generation on gate-level model.
References: 1. PatelJ. H. Stuck-at Fault: A fault Model for the Next Millennium // Proc. of the International test Conference 1998. P. 1166. 2. Devadas S., Ghosh A., Keutzer K. An Observability-Based Code Coverage Metric for Function Simulation // Proc.ACM international Conference on Computer Aided Design, 1996. P. 418424. 3. Fallah F., Devadas S., Keutzer K. OCCOM: Efficient computation of Observability-Based code Coverage for Functional Verification // Proc. 34 th. Design Automation Conference, 1998. 4. CornoF., Sonza Reorda M., Squillero G. High-Level Observability for Effective High-Level ATPG // VTS-2000, IEEE VLSI Test Symposium, May 2000. P. 411-416. 5. Ferrandi F., Fummi F., Sciuto D. Implicit test Generation for Behavioral VHDL Models”, Proceedings IEEE International T est Conference, 1998. P. 587-596 6. Rudnick E.M., Vietti R., Ellis A., Corno F., Prinetto P., Sonza ReordaM. Fast sequential circuit test Generation Using High-Level and Gate- Level Techniques”, Procedings IEEE European Design Automation and Test Conference, 1998.
Figure 6. Time-to-market dependency on design flow stages
76
R&I, 2003, Ns 3
