REALIZATION-INDEPENDENT TESTING OF DIGITAL SYSTEMS R. Šeinauskas Kaunas University of Technology...
-
Upload
sophia-wilcox -
Category
Documents
-
view
214 -
download
0
Transcript of REALIZATION-INDEPENDENT TESTING OF DIGITAL SYSTEMS R. Šeinauskas Kaunas University of Technology...
REALIZATION-INDEPENDENT TESTING OF DIGITAL SYSTEMS
R. ŠeinauskasKaunas University of Technology
LITHUANIA
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
IntroductionIntroduction
Idea, Algorithm
RTL Description
Gate Level Netlist
Layout
Defect-Based Test Generation
Defects
Conventional Test Generation
Fault model of gates
High-Level Test Generation
Description distortion model
Test Generation for Algorithms
Black-box fault model
Test Generation TasksTest Generation Tasks
Conventional Test Generation
Fault model of gates
High-Level Test Generation
Description distortion model
Test Generation for Algorithms
Black-box fault model
Defect-Based Test Generation
Defects
Test generation for all possible realizations of circuit
description
Test generation for defects
Test generation for all possible realizations of cells
Test generation for all possible descriptions and all possible
realizations of circuit
ASIC Design Flow
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 of the test activities (test structure insertion, test vector generation, fault coverage evaluation, etc,) are still performed on the gate-level netlists.
Drawbacks
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
Time-to-Market
Time-to-Market depends on the duration of the logic and layout synthesis and on the duration of the design for test and test generation.
The design for test and test generation on the system level-level model can reduce time-to-market.
Starting test development at the end of the design process greatly prolongs the time-to-market.
System-level model
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.
Time-to-Market
System-level model
RT-level model
Gate-level model
Layout DFT and Test generation
DFT and Test generation
DFT and Test generation
DFT and Test generation
Design complexity
Design complexity drives the need to reuse legacy or IP ( intellectual Property) cores in Systems on a chip ( SoC).
High Level modules of SoC are often specified in terms of their behavior only.
SoC designs rely heavily on reusable and pre-designed cores or intellectual property ( IP) modules, whose gate-level implementation details are unavailable.
Test reuse
Systems designers become system architects reusing more and more proven components and their test processes.
Test reuse must follow the same path. Conventional single–at fault models associated
with internal logical gates or their inter connections are not applicable for test reuse.
Structural defect-based test involves no test reuse, as tests are usually generated after structural synthesis.
Reusable tests
The implementation depends on SoC manufacturing technologies and is permanently changing in SoC lifecycle.
Time-to-Market, reuse legacy or IP cores in Systems on a chip design drives the need to use realization-independent testing.
How core vendors can provide reusable tests for new implementations?
Important questions
Can a test based on functional fault model be effective in uncovering physical defects?
How is its effectiveness dependent on the synthesized structure?
These are important questions, not only for test reuse, but also due to fact that soft cores can be synthesized by different electronic design automation systems, and mapped in different cell libraries and manufacturing technologies.
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
Realization-independent testing
Test generation on system-level model cannot guarantee the complete fault coverage on gate-level model for each possible realization
Time-to Market depends on ASIC design flow process.
Design Flow
System-level model
Gate-level model
SynthesisDFT and Test
generation
Time-To-Market
System-level
model
Synthesis
DFT and Test generation
Gate-level model
Test sequences
Test supplement on switch-level
model
Test supplement on
System-level model
Defect coverage analysis
Design Flow
In any case fault coverage analysis on gate level model is necessary, but it is not time consuming task.
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.
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
The influence of circuit re-synthesising
on the fault coverage
The core can be synthesized by different electronic design automation systems, and mapped in different cell libraries and manufacturing technologies.
An important issue is how the test set of the core covers the faults of new implementations, which are done by the same synthesizer.
The experiments have been done with ISCAS’85 benchmarks.
Three realizations
The original ISCAS’85 circuits have been re-synthesized with Synopsys Design Compiler program by default mode and by using AND-NOT cell library of two inputs.
The test sets have been generated for each original ISCAS’85 circuit and for each re-synthesized circuit by deterministic algorithm and by random plus deterministic algorithm.
The fault coverage of each test set for each circuit realization was computed
Three RealizationsCircuits Non redundant ISCAS’85
circuitsSynopsys Design
Optimization- class.dbSynopsys Design Optimization-
and_or.db
Test Size # of Stuck-at faults
Test Size # of Stuck-at faults
Test Size # of Stuck-at faults
C432 63 507 47 426 50 460
C499 63 750 78 978 90 1246
C880 54 942 51 857 54 928
C1355 92 1566 100 1616 110 1406
C1908 123 1862 60 876 81 1224
C2670 113 1990 120 1500 114 1658
C3540 172 3126 144 2474 143 2520
C5315 130 5248 92 3879 97 4130
C6288 34 7638 49 6680 39 7498
C7552 209 7039 154 4578 136 4798
Test size of realizations
Test Size for realizations
0
50
100
150
200
250
C43
2
C49
9
C88
0
C13
55
C19
08
C26
70
C35
40
C53
15
C62
88
C75
52
ISCAS'85 benchmarkcircuits
Synthesis withtarget library class.db
Synthesis with targetlibrary or.db
Three realizations
The number of stuck-at faults
0100020003000400050006000700080009000
C43
2
C49
9
C88
0
C13
55
C19
08
C26
70
C35
40
C53
15
C62
88
C75
52
ISCAS'85 benchmarkcircuits
Synthesis withtarget library class.db
Synthesis with targetlibrary or.db
Deterministic test patterns (Synopsys ATPG)
Circuits
Non redundant ISCAS’85 circuits
Synopsys Design Optimization- class.db
Synopsys Design Optimization- and_or.db
Test Size
#Stuck-at faults of two otherrealization
Undetected faults of two other realization
Test Size
#Stuck-at faults of two other realization
Undetected faults of two other realization
Test Size
#Stuck-at faults of two other realization
Undetected faults of two other realizationC432 63 886 11 47 967 29 50 933 25
C499 63 2224 160 78 1996 28 90 1728 24
C880 54 1785 0 51 1870 36 54 1799 20
C1355 92 2712 45 100 2972 18 110 2882 24
C1908 123 2100 4 60 3086 199 81 2738 141
C2670 113 3158 65 120 3648 32 114 3490 25
C3540 172 4994 12 144 5646 65 143 5600 59
C5315 130 8009 20 92 9378 82 97 9127 94
C6288 34 14178
57 49 15136
27 39 14318
21
C7552 209 9376 41 154 11837
206 136 11617
285
Total 1053
49422
415 895 56536
722 914 54232
718
Percent
0,84%
1,28%
1,32%
Undetected faults of two other realizations
Number of undetected faults
0
50
100
150
200
250
300
C432
C499
C880
C1355
C1908
C2670
C3540
C5315
C6288
C7552
Non-redundantISCAS'85 benchmarkcircuits
Synopsys designoptimization, targetlibrary-class.db
Synopsys designoptimization, targetlibrary-and_or.db
Circuits Non redundant ISCAS’85 circuits Synopsys Design Optimization- class.db
Synopsys Design Optimization- and_or.db
Test Size #Stuck-at faults of two otherrealization
Undetected faults of two other realization
Test Size
#Stuck-at faults of two other realization
Undetected faults of two other realization
Test Size
#Stuck-at faults of two other realization
Undetected faults of two other realization
C432 57 886 5 46 967 20 45 933 18
C499 54 2224 82 74 1996 20 80 1728 24
C880 62 1785 1 49 1870 17 50 1799 18
C1355 86 2712 0 100 2972 8 80 2882 24
C1908 118 2100 2 57 3086 212 75 2738 131
C2670 105 3158 79 120 3648 30 116 3490 35
C3540 167 4994 10 143 5646 69 147 5600 60
C5315 130 8009 20 99 9378 82 89 9127 121
C6288 43 14178 100 47 15136 9 34 14318 28
C7552 211 9376 25 146 11837 239 138 11617 273
Total 1033 49422 324 881 56536 706 854 54232 732
Percent Max. –3,68% 0,66% Max. –6,86% 1,25% Max. –4,78% 1,35%
Random plus deterministic test patterns (Synopsys ATPG)
Circuits Non redundant ISCAS’85 circuits Synopsys Design Optimization- class.db
Synopsys Design Optimization- and_or.db
Test Size #Stuck-at faults of two otherrealization
Undetected faults of two other realization
Test Size #Stuck-at faults of two other realization
Undetected faults of two other realization
Test Size #Stuck-at faults of two other realization
Undetected faults of two other realization
C432 120 886 2 93 967 10 95 933 9
C499 90 2224 49 117 1996 10 152 1728 6
C880 116 1785 0 100 1870 5 104 1799 9
C1355 178 2712 0 183 2972 4 190 2882 8
C1908 241 2100 2 117 3086 130 156 2738 80
C2670 218 3158 27 240 3648 17 230 3490 7
C3540 339 4994 3 287 5646 24 290 5600 20
C5315 260 8009 1 191 9378 24 186 9127 30
C6288 77 14178 4 96 15136 0 73 14318 2
C7552 420 9376 4 300 11837 142 274 11617 147
Total 2059 49422 92 1724 56536 366 1750 54232 318
Percent Max. –2,20% 0,19% Max. –4,21% 0,65% Max. –2,92% 0,59%
Merged two sets
Percent of undetected faults
0,00%
0,20%
0,40%
0,60%
0,80%
1,00%
1,20%
1,40%
1,60%
ISCAS'85benchmark
circuits
Synthesiswith target
libraryclass.db
Synthesiswith target
libraryand_or.db
Deterministic test set
Random test set
Deterministic andrandom test sets
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
All possible realizationsAll possible realizations
Universal test sets
All possible realizations
Universal test sets
Realization-independent testing is based on the concept of a universal test set.
The testability properties of different forms of two-level AND-EXOR networks have attracted many researchers.
Realization-Independent Tests
The size of the universal test sets is small for functions that are fully unate, but it becomes exhaustive for binate functions.
In general, it exploits the unateness property of a module’s variables, and is composed of functionally defined minimal true and maximal false tests.
A universal test set can detect both single and multiple stuck-at faults in realizations with restrictions on their structure.
Unate-gate networks
It has been proved that the universal test set detects all MSL faults in a realization R under the following restriction:
every path between two points in R (excluding the stems of primary inputs) has the same inversion parity;
these realizations are called unate-gate networks
Balanced inversion parity ( BIP) network
The unate-gate restriction is strict and practically it is often replaced by relaxed condition.
Realization R of function is a balanced inversion parity ( BIP) network, if paths from unate variables have same inversion parity.
BIP realizations allow paths with different inversion parities between any binate variable and the outputs of a network, and so apply to any practical realization.
BIP realization
It has been shown recently that in the worst case unate-gate networks are at most twice as large as the minimal implementation.
BIP realizations, on the other hand, tend to be minimal or near-minimal.
Any BIP realization can be obtained from a unate-gate network by applying a set of resubstitution and De Morgan transformation..
The size of the universal test set
Universal test set detects all detectable multi stuck-at faults in BIP realization.
The size of the universal test set for a unate function is relatively small, but for a binate function equals the size of exhaustive test.
The exhaustive test (2n) includes all possible test vectors of n inputs.
Complete test set
In general case it is impossible to get a complete test set less than the exhaustive test without information about concrete realization of the module.
The complete test detects all single stuck-at faults of the module described in terms of primitive gates.
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
A cell fault
A cell fault implicitly models all defects that alter a module’s truth table and so provides a high degree of realization independence.
However, this model can only be applied to very small modules, because often it requires an exhaustive test set comprising all possible input vectors.
The input pattern fault model
The input pattern fault model uses a true table of function as well.
Each input pattern fault defines an input and output pattern pair and corresponds the faulty behavior of module.
The number of faults for even small modules is large.
The coupling faults
The coupling faults can alter output values in response to changes occurring on one or more inputs of a function
The simplest case is a single coupling fault, which is defined in terms of a single input/output signal pair.
The coupling test sets share some properties with universal test sets, but are not necessarily exhaustive for binate functions.
The coupling test sets are enough large even for small functions
Higher-level fault models
Higher-level fault models have been proposed for realization-independent functional testing of combinational circuits.
Logic/arithmetic operations, constant/ variable switch, null statements, if/else, case, for instructions considered as RTL fault models.
In some cases, their effectiveness in covering stuck-at faults on the circuit’s structural description has been ascertained. However, this does not guarantee their effectiveness to uncover physical defects or stuck-at faults.
The high-level fault models
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.
Other approaches
Some approaches rely on a direct examination of the HDL description or exploit the knowledge of the gate-level implementation. Some extract of the corresponding control machine from a behavioural description is used.
The listed approaches are of limited generality and the adequacy of testing defects or of the coverage stuck-at faults on the gate level are not proved.
Black-box view
The behavioral view or “black-box” represents the system by defining the behavior of its outputs according to values applied on its inputs without knowledge of its internal organization.
In this case only the input-output connectivity can be fixed. The connectivity fault models are rough enough compared to the stuck at fault model. However, the experimental investigation of fault models based on input-output paths testing demonstrated high defect and stuck-at fault coverage on the benchmark circuits.
The n –detection test sets
An n –detection test set is one where each modeled fault is detected either by n different tests, or by the maximum number of different tests that can detect the fault if this number is smaller than n.
In various types of experiments reported, n detection test sets were shown to be useful in achieving high defect coverage for all types of circuits and for different fault models..
The Pin Pair fault model
Let the circuit have a set of inputs X = {x1, x2, ... ,xi, ... ,xn} and a set of
outputs Y = {y1, y2, ... ,yj, ... ,ym}.
The pin fault model considers the stuck-at-0/1 faults occurring at the module boundary
Input-output pin stuck-at fault pairs (xit, zj
k),
t=0,1, k=0,1 are called pin pair faults (PP).
Testing of the PP fault
The test vector detects the pin pair fault (xit, zj
k) of the module if the test vector detects both the pin faults xi
t, and zjk of the pair on the output zj of the
module. The PP fault (xi
t, zjk) of a module is testable if a
conventional deterministic test generator for a realization of the module finds a test vector, which detects a pin fault xi
t on an output zj while the input xi and the output zj are set up to the ¬t and ¬ k
DemonstrationDemonstration
Circuit0 1
0 0
0
1
0
1
0
1
DemonstrationDemonstration
Circuit0 1
1 1
0
1
1
0
1
0
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
Fault and Test SetsCircuits Stuck-at
FaultsTest size Connectivity
FaultsTest size
C432 507 63 540 122
C499 750 63 5184 1053
C880 942 54 1326 379
C1355 1566 92 5184 1023
C1908 1862 123 3004 620
C2670 1990 113 3320 461
C3540 3126 172 2588 513
C5315 5248 130 10540 1113
C6288 7638 34 3068 246
C7552 7039 209 12188 1681
Stuck-at Fault CoverageCircuit Undetected
of R1Undetected
of R2Undetected
of R3
C432 11 (2,2%) 6 (1,4)% 3 (0,7%)
C499 0 0 0
C880 0 0 0
C1355 0 0 1
C1908 64 (3,4%) 9 (1.0%) 9 (0,7%)
C2670 8 (0,4%) 7 (0,5%) 6 (0,4%)
C3540 35 (1,1%) 25 (1,0%) 30 (1,2%)
C5315 0 0 0
C6288 0 0 0
C7552 25 (0,4%) 8 (0,2%) 4 (0,1%)
Total 143 (0,5%) 55 (0,2%) 53 (0,2%)
R1 – The non-redundant ISCAS’85 benchmark circuitR2 – Synopsys Design Optimization , the target library – class.dbR3 - Synopsys Design Optimization, the target library – and_or.db
PP Fault CoverageCircuits Connectivit
yFaults
Deterministic tests Random+deterministic tests
Detected Percent Detected Percent
C432 540 406 75,13 467 86,48
C499 5184 1510 29,13 1434 27,66
C880 1326 837 63,12 862 65,01
C1355 5184 2718 52,43 2638 50,89
C1908 3004 1521 50,63 1740 57,92
C2670 3320 2204 66,38 2142 64,51
C3540 2588 2051 79,31 2036 78,73
C5315 10540 7148 67,88 7305 69,30
C6288 3068 2353 76,74 2393 77,99
C7552 10262
Total 45016 20748 59,69 21017 60,47
Circuits Non redundant ISCAS’85 circuits Synopsys Design Optimization- class.db
Synopsys Design Optimization- and_or.db
Test Size #Stuck-at faults of two otherrealization
Undetected faults of two other realization
Test Size #Stuck-at faults of two other realization
Undetected faults of two other realization
Test Size #Stuck-at faults of two other realization
Undetected faults of two other realization
C432 122 886 7 122 967 26 122 933 21
C499 1053 2224 0 1053 1996 0 1053 1728 0
C880 379 1785 0 379 1870 1 379 1799 1
C1355 1023 2712 1 1023 2972 1 1023 2882 0
C1908 620 2100 12 620 3086 57 620 2738 59
C2670 461 3158 8 461 3648 14 461 3490 10
C3540 513 4994 39 513 5646 65 513 5600 50
C5315 1113 8009 0 1113 9378 0 1113 9127 0
C6288 246 14178 0 246 15136 0 246 14318 0
C7552 1728 9376 39 1728 11837 111 1728 11617 108
Total 7258 49422 106 7258 56536 275 7258 54232 249
Percent Max. –0,78% 0,21% Max. –2,69% 0,49% Max. –2,25% 0,46%
Black-box test connections tested at least once
Circuits Non redundant ISCAS’85 circuits Synopsys Design Optimization- class.db
Synopsys Design Optimization- and_or.db
Test Size #Stuck-at faults of two otherrealization
Undetected faults of two other realization
Test Size #Stuck-at faults of two other realization
Undetected faults of two other realization
Test Size #Stuck-at faults of two other realization
Undetected faults of two other realization
C432 468 886 0 468 967 4 468 933 4
C499 6221 2224 0 6221 1996 0 6221 1728 0
C880 1381 1785 0 1381 1870 0 1381 1799 0
C1355 6186 2712 0 6186 2972 0 6186 2882 0
C1908 2968 2100 6 2968 3086 16 2968 2738 18
C2670 1922 3158 2 1922 3648 2 1922 3490 4
C3540 1997 4994 11 1997 5646 16 1997 5600 13
C5315 5507 8009 0 5507 9378 0 5507 9127 0
C6288 1262 14178 0 1262 15136 0 1262 14318 0
C7552 5004 9376 26 5004 11837 74 5004 11617 76
Total 32916 49422 45 32916 56536 112 32916 54232 115
Percent Max. –0,28% 0,09% Max. –0,63% 0,20% Max. –0,66% 0,21%
Black-box test connections tested at least twice
Percent of undetected faults
0,00%
0,20%
0,40%
0,60%
0,80%
1,00%
1,20%
1,40%
1,60%
ISCAS'85benchmark
circuits
Synthesiswith target
libraryclass.db
Synthesiswith target
library or.db
One deterministictest set
Two deterministicand random testsets
Test set for testing ofconnections
Test set for twice testing ofconnections
Maximum and on average percent of undetected faults
Maximum percent of undetected faults
On average percent of undetected faults
One test set 7,19 1,12
Two test sets 4,21 0,48
Test set for testing of connections
2,69 0,39
Test set for twice testing of
connections
0,66 0,17
Flowchart
System-level model
Gate-level model
SynthesisDFT and Test
generation
Time-To-Market
System-level
model
Synthesis
DFT and Test generation
Gate-level model
Test sequences
Test supplement on switch-level
model
Test supplement on
System-level model
Defect coverage analysis
Test set compaction
Test sets could be compacted according to the defects of circuits only
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 or switch-level models
Software testing
Connectivity testing is applicable for software testing as well
Software runs on some hardware indeed The question is open how connectivity tests
detect software faults
Test generation for algorithms
The simplest approach for black-box test generation is selection test vectors from random generated according to the connectivity criteria.
The random search can be stopped if fixed amount of generated vectors did not detect new connectivity between input and output
Test generation procedure
Each input vector has sensitive inputs, which value change impact the outputs
The input vectors adjacent to the sensitive inputs have to be evaluated
The evaluated input vectors have new adjacent input vectors of sensitive inputs and so on.
Test generation procedure
The procedure continues until no vector have been selected from the new set of adjacent input vectors
The new random input vector will be generated for repeated search in this case
The procedure terminates due to low efficiency of search
ExampleExample
0000
1111
1000
1100
0100
0011
0001
0010
11101101
1010
0101
1011
0111 0110
1001
Tools on the internetTools on the internet
http://www.http://www.elenelen..ktuktu..ltlt//etgetg/results.html/results.html Online test synthesis tool. Interface Online test synthesis tool. Interface
through browserthrough browser Black-box model on CBlack-box model on C Registration, passwordRegistration, password
Outline
Introduction Design flow The influence of circuit re-synthesising on the
fault coverage Universal test setsUniversal test sets High-level fault modelsHigh-level fault models Test Generation CapabilitiesTest Generation Capabilities for the Black-Box model for the Black-Box model Conclusions
Conclusions
Test of black-box are realization independent and can be reused by software and hardware implementations of algorithm.
Re-synthesizing of circuit with different target libraries and test reuse can not detect about one percent of stuck-at faults.
Conclusions
The design for test and test generation on system-level model reduces time-to-market
Test generation on system-level model can not guarantee the complete fault coverage on gate-level model for each possible implementation
Conclusions
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.
Black-box fault models ensure fault detection on gate-level model like two-detection test for re-synthesized circuit with different target libraries