Hans-Bunte-Str. 19 ... stuck-at fault model [1] still dominates the industry in prac- tice. Thus, the ... It has been observed over many years that stuck-at faults.
Simulating Realistic Bridging and Crosstalk Faults in an Industrial Setting Jonathan Bradford
Hartmut Delong
Micronas GmbH Hans-Bunte-Str. 19 79108 Freiburg im Breisgau, Germany
bradford, delong @micronas.com
Abstract Three different techniques for simulating realistic faults generated from IC layout are discussed. Two of them deal with bridging faults, and the third one handles crosstalk faults. The simulation is performed on top of a commercial simulator and thus is very well applicable in an industrial environment. No change of the design database and only minimal changes of the test shell are required. Experimental results are reported for a library cell and a block from a full-custom design. Keywords: Fault simulation, Defect-based testing, Industrial experiences, Crosstalk
Ilia Polian
polian,becker @informatik.uni-freiburg.de
1 Introduction For today’s designs, the gap between defects and faults increases at an ever rising rate. Defects [24] are physical failures, caused by, for instance, missing or extra material on some layer, impurities of substances used for manufacturing, or equipment failure. In contrast, faults are attempts to adequately describe defects with some level of abstraction. The stuck-at fault model [1] still dominates the industry in practice. Thus, the quality of test programs used for detection of defective manufactured ICs is assessed in terms of stuck-at fault coverage. On the other hand, semiconductor companies normally have a target PPM (defective parts per million) value, that is the maximal number of ICs in a million, which passed the testing procedure and thus were shipped although in reality being defective. Since every such test escape causes substantial costs (often considerably exceeding the margin), lowering the PPM value is worth serious effort. Moreover, sometimes some PPM level is contractually guaranteed to a customer. It has been observed over many years that stuck-at faults cover only a small subset of all possible manufacturing defects (for example shorts of a wire with or ground). Though test sets with high stuck-at coverage lead to an acceptable escape rate in the past, new PPM targets in conjunction with new types of defects in todays nanometric technology weaken its unique position. That’s why the pool of methods jointly known as defect-based testing (DBT) is now becoming interesting for the semiconductor industry. main research directions in DBT are: The Identifying real defects using manufacturing process data, IC dissection, ion beam slicing, optical inspection [32], process monitors [34], etc.
Bernd Becker
Albert-Ludwigs-University Georges-K¨ohler-Allee 51 79110 Freiburg im Breisgau, Germany
Deriving the actual behaviour of a defective IC by evaluating defective ICs or physical defect insertion [2]. Furthermore, low-level electrical simulation tools based on Kirchhoff’s Laws (such as SPICE) are commonly considered to be accurate enough for estimating the behaviour of an IC containing specific defects. Also other simulation-based methods [20, 18, 35, 14] have been proposed. Creating realistic fault models [2, 33, 26, 10, 8, 12] on higher level (gate level, RTL [31, 16, 5, 23, 4]) representing real defects. Evaluation of (existing) test programs by means of Defect coverage, a metric for efficiency in detecting real defects instead of a synthetic measure with no direct relationship to the defects like stuck-at fault coverage [2]. Here, the realistic fault models mentioned above may be employed. A question of special interest in quality management is: ‘my test program has high stuck-at fault coverage. Does it also cover a high percentage of real defects?’ Test pattern generation for detecting real defects. Explaining yield figures (Yield Learning [25]) and predicting yield or related values (like Quality Level [7]). Defining Design-for-Manufacturability (DfM) measures [36] in order to increase the yield in the future.
Compared to this variety, only few cases of actual use of these techniques in the industry have been published (e. g. [34, 2, 26, 38, 37, 22]). Some of the published works exclusively deal with dedicated types of circuits (for example SRAMs [25, 17]). There is a tremendous range of different defect mechanisms, and even more actual defects. If for instance, we consider only particle-induced defects, we have to consider the conductance of the particle, its shape, size, evaporation temperature, its position on the die and the manufacturing step in which it ends up on the die [19]. If we take into account the fact that a defect may be caused by more than one particle, we get even more potential defects. In this work, we concentrate on circuit misbehaviour caused by shorts on a conducting layer (bridges). To deal with these defects, pairs of objects located close enough have to be identified. (The question how to define ‘close enough’ can be answered in a couple of ways [34, 9]) For non-trivial circuits, the only cases in which this task can be done manually are very regular structures (like memories). For a random logic block of reasonable size, an automated approach (e. g. one based on evaluation of layout of this layer) appears
to be the only option. After a list of real defect candidates is generated, the following questions are of interest for each potential short: does it lead to a functional misbehaviour of the IC? (for instance, shorts between two connected or otherwise logically equivalent lines normally do not.) If yes, how is the behaviour affected? Does one line (aggressor) dominate the other (victim)? Does the bridge behave like an AND- or an OR-gate? Does the bridge behaviour depend on the strength of the involved signals? Or is a SPICE simulation the only way to find out the new function? Most effects of a short defect listed above are traditionally modeled as bridging faults. A further defect mechanism which dramatically gained in importance for nanometric technology, is crosstalk [6, 39, 21]. Under this term, the following misbehaviour is understood: A signal (or a signal change) on a wire (or several wires), called aggressor wire(s), affects a signal (or a signal change) on one or more wire(s), called victim wire(s), in an unintended way. In todays terminology, crosstalk mostly means either change of switching delay or a (short) pulse on the victim wire. In contrast, ‘normal’ bridging faults leading to the opposite logic value on a wire for the duration of the whole cycle are not classified as crosstalk. Crosstalk defects are normaly induced by shorts with high resistance. A cause for such resistive short may be a conducting particle which touches only one wire but is located close enough to the other wire to establish a connection having non-infinite resistance. Thus, wires located next to each other on the conducting layers, and especially wires which are running in parallel at small distance, are good candidates for crosstalk. After the location of candidate defects is known and the behaviour of the IC with these defects present is understood, the whole arsenal of DBT methods becomes available. The defect coverage (with respect to shorts on conducting layers) of used test patterns can be estimated by simulation. Modifications or enhancements of the patterns may become necessary if the defect coverage should be too low. Of special interest are the defects which have not been detected by employed test patterns. They should then be targeted by a second iteration of the test pattern generation process. In case some features are too close to each other, modifying the layout (increasing the distance) may be an appropriate Design-for-Manufacturability measure (so the fault will not be prevented from escaping the test but will be prevented from appearing at all, thus increasing yield). As can be seen in the list above, fault simulation with such a derived realistic fault model is crucial to the whole process. However, several problems emerge:
Simulating a block of considerable size with SPICE is not realistic in terms of time and memory requirements. For bridging faults, there exists a couple of methods which find some trade-off between accuracy and ressource requiriments for the simulation [29, 28, 27, 15, 11, 3, 13, 30]. The corresponding tools were mostly academic developments. Thus, some of them may not support design artefacts such as tri-state buffers, dynamic logic, etc.
The academic tools often have no or only a weak interface to commercial tools, so the design data base has to be converted into a format the tool can understand. Information crucial for correct simulation can be lost during the conversion process. Therefore, the use of the commercial tools for simulating real defects is a highly desirable goal. However most tools provide only a basic support (if any) of such simulation techniques and also unfortunately these features do not seem to be a high priority for tool vendors. Furthermore most users have no access to the source code of the tools, so the capacity for adding functionality to the tools is somewhat restricted. In this paper we present a simulation technique which was developed during the cooperation between Micronas and the University of Freiburg. Micronas develops and manufactures multimedia, audio/video and automotive ICs. For (stuck at) is used. Verifault fault simulation Cadence Verifault offers only basic support for wired-and and wired-or bridging faults. Furthermore, simulations using these options lead to instabilities in our experiments, and we observed simulation time and memory explosion even for quite small design parts. Thus, we identifiedstuck-at faults as the only usable fault models in Verifault . Micronas full-custom designs contain a large number of dynamic logic elements, feedback loops and asynchronous blocks, which make automatic extraction of net list at gate level impossible. Since all tools available at the University of Freiburg deal with (some kind of) gate-level net lists, their techniques cannot be applied. In contrast, the technique presented in this paper is used in Micronas design flow, providing, in addition to the stuck-at coverage, information on coverage of realistic faults. Contrary to module mutation technique [16], for which a fault injection is performed by replacing the correct module with a faulty (mutant) module, no modification of the design database is required. The rest of the paper is organized as follows: in Section 2, two bridging fault models within the proposed simulation technique are presented. The description of the crosstalk model follows in Section 3. Experimental results are given in Section 4. Section 5 concludes the paper.
2 Simulation Technique for Bridging Faults In Verilog, each wire is driven by one or possibly more blocks (logic gates, transistors, etc.) Each block connected to a wire either pulls it up (tries to assign the logic value of 1 to the wire) or down (tries to write the logic value of 0). The driving blocks have some specific strength with which they are driving a wire. If a wire is simultaneously pulled up and down by two (or more) blocks, the one having the highest strength wins. If several blocks drive complementary values with the same strength, the unknown-state value X is assigned to the wire. In this work, we concentrate on shorts caused by conductive particles, which are modeled as bridging faults. The list of realistic defects of this type is automatically generated from layout data. Thus, we have a ‘realistic bridging fault list’.
2.1 Transistor Model If there is a bridge between two wires w1 and w2 in the design, then a conductive connection between w1 and w2 is present. If there is no bridge between w1 and w2, then there is also no connection (at least not at this location). This is somewhat like the property an abstract transistor has: it establishes a connection between source and drain if its gate is driven by logic 1 value and does not establish a connection if logic 0 value is applied. In the Transistor Model, we use this property of a transistor to reduce a bridging fault to a stuck-at fault. This results in the module bridge tran1 . module bridge tran(b1, b2); inout b1, b2; supply0 enable bridge; tranif1(b1, b2, enable bridge); endmodule Figure 1: Verilog code of the Transistor Model module
b1
w1
enable_bridge stuck-at-1
b2
w2
Figure 2: Transistor Model
The Verilog code of the module bridge tran is given in Figure 1. In Figure 2, the situation is illustrated. A potential bridging fault between w1 and w2 can be modeled by introducing the following Verilog declaration: bridge tran BT(w1, w2); Thus, the wires w1 and w2 are connected to source and drain nodes of a transistor whilst its gate is connected to the ground (supply0) via the wire enable bridge and thus held at 0. In this constellation, the transistor does not affect the operation of the device. The bridging fault between w1 and w2 is now equivalent to the stuck-at-1 fault at the wire enable bridge of the module BT. Thus, the fault declaration fault net sa1 BT.enable bridge; has the same effect as the declaration of a bridging fault between w1 and w2. This declaration can be placed into the fault declaration file. Thus, given a list of potential shorts (extracted from layout), two lists have to be generated: the list of 1 The models we are using are somewhat similar to models from [31], where, however, variations of biased voting models are employed and a hence a set of additional electrical parameters is required.
bridge tran instances and hierarchically nested identifiers to aggressor and victim nets w1 and w2 (which are inserted in the top level module) and the list of stuck-at-1 faults on the enable bridge wires. Then the fault simulation can be run with the new fault list. Note that for Verifault stuck-at fault simulation rather than bridging fault simulation now takes place, so all features available for stuck-at fault simulation are available. Especially the parallel fault simulation functionality with its performance implication may be of great importance in an industrial setting. The fault coverage determined by fault simulation corresponds to the coverage of short defects. Undetected and aborted faults can be written out into a file, thus indicating to the test engineer that improvements should be done to the test patterns. The generation of both lists of bridge tran modules and the stuck-at-1 faults on the enable bridge wires can be easily automated by software. The changes in the existing design are restricted to inclusion of these two lists. Both inclusions can be performed by writing the lists into separate files and using Verifault inclusion directives and $fs read. If the fault list changes later, only these two files have to be replaced with the rest of design remaining as it is.
2.2 Dominance Model The Transistor Model appears to be an elegant, straight forward method to reduce the bridging faults to stuck-at faults, that can be handled by commercial tools. However the experimental results were somewhat disappointing. Not only the enormous run-time requirements of the ‘stuck-at faults’ representing bridging faults (compared to convential stuck-at faults) turned out to be a problem. Even worse, there were no clear figures indicating the fault coverage. In fact, mostfaults terwere classified as ‘potentially detected’. In Verifault minology, this means that a logic 1 or logic 0 value was observed for the good machine, and the unknown value X was observed for the faulty machine. (Even switching off the option to drop potentially detected faults from the fault list did not help). Thus for most faults there was no information whether they are detected, not detected, or sometimes detected. This situation can be explained by looking at the Verilog tranif1 primitive in more detail. If the source and the drain node of the transistor (b1 and b2 in Figure 1) are driven to opposite logic values with the same strength, then they are both set to the unknown value X. However, a bridging fault can only be detected if the two bridged nodes have opposite logic values. Thus, if the values required for detection of the bridging fault have been justified, the bidirectional Transistor Model will make X values out of both in most cases. These X values then propagate rapidly to the observable points, leading to only a potential detection of the fault. The only case which can lead to a detection is two bridged wires driven to opposite values with different strength. If, for instance, the wire w1 in Figure 1 is driven to a strong 1, and the wire w2 is driven to a weak 0, then setting enable bridge to 1 (letting the transistor conduct) will assign the value 1 to w2. Thus, on the wire w2 the good and
the faulty machines will have opposite values. This ‘hard difference’ then can be propagated to an observable point, causing detection of the bridging fault under consideration. The results have shown that such cases are rare. The performance impact can be explained with the fact that, though no SPICE-like simulation takes place, tranif1 is one of the most expensive Verilog primitives in terms of simulation effort. Especially the bridging faults between the wires in different modules seem to cause timeconsuming internal switches between the HDL simulation mode and the gate-level simulation mode. To fight the inaccuracy and the performance implications of the Transistor Model, we designed the Dominance Model. The Verilog code of the module bridge dom used in this model is given in Figure 3. The usage of this module exactly corresponds to the usage of the module bridge tran from the Transistor Model. module bridge dom(aggr, victim); inout aggr, victim; supply0 enable bridge; assign (supply0, supply1) vict = (enable bridge) ? aggr : 1’bz; endmodule Figure 3: Verilog code of the Dominance Model module In the Dominance Model, Aggressor/Victim behaviour of the bridge is assumed: let w1 and w2 still be the wires involved in the bridge. Then, the statement bridge dom BT(w1, w2); will have the following effect: w1 is the hierarchical reference of the aggr signal, w2 is the hierarchical reference of the victim signal. A stuck-at 1 fault on the control signal BT.enable bridge implies that the value of aggr (w1) overrides the value of victim (w2). So, the bridging fault behaviour can be described by the sentence ‘the wire w1 dominates the wire w2’. Note that the few detected faults in the Transistor Model also had this kind of behaviour. Unlike the Transistor Model module bridge tran, the module bridge dom is not bidirectional: given a bridge between the lines w1 and w2, the fault declarations bridge tran BT1(w1, w2) and bridge tran BT1(w2, w1) would lead to two equivalent faults. In contrast, the declarations bridge dom BT1(w1, w2) and bridge dom BT1(w2, w1) describe different types of faulty behaviour: in the former case, the wire w1 dominates the wire w2. In the latter case, w2 dominates w1. Thus, two fault declarations are required for each bridge under the Dominance Model. Modeling bridges with ground and may help reduce computational complexity. Generally, other bridge behaviour types can be modeled in similar way.
3 Simulation Technique for Crosstalk As mentioned in the introduction, the modern understanding of crosstalk includes delay implications and pulses on the victim wire. In this work, we concentrate on the latter defect mechanism. module xrf glitch(aggr, vict); inout aggr, vict; parameter gltime = 10; reg active; always begin @(aggr); active = 1; #(gltime) active = 0; end supply0 enable xrf; assign (supply0, supply1) vict = (enable xrf && active) ? aggr : 1’bz; endmodule Figure 4: Verilog code of the Crosstalk Model module
Similar to the Dominance Model for bridging faults, there is an aggressor and a victim wire in the Crosstalk Model. This module can be easily enhanced to handle crosstalk defects with more than one wire of each type involved, which is omitted here for conciseness. If the wire w1 is supposed to be an aggressor and w2 is supposed a victim in a crosstalk defect, the statement xrf glitch XRF(w1, w2); must be included, and a stuck-at 1 fault must be injected on the signal XRF.enable xrf. Then, following behaviour will take place: If there is an event (a signal change) on the wire w1, then the internal signal active will be set to 1 for the duration of gltime nanoseconds. Note that the parameter gltime has a default value of 10 ns, but it can be set for each instance of xrf glitch to different values from outside of the module. For instance, if there is an instance XRF1 and an instance XRF2, you can set XRF1.gltime to 5 and XRF2.gltime to 15. After gltime nanoseconds, active is set back to 0. The victim signal w2 is forced to assume the value of w1 if and only if following conditions hold: first, the crosstalk defect must be enabled (enable xrf must be 1) and the pulse must still persist (active must be 1, too). This is controlled by the last statement in module’s code.
Method Transistor Transistor, No Drop Potential Dominance
Detected 12.3 24.8
Potentially Detected 87.3 33.8
99.6
0
Dropped due to Loop Hyper Active 0 0.4 0 41.4 0.4
0
Undetected 0 0 0
Ressources CPU Time Memory 831 sec 42 MB 87.3 hours 68 MB 486 sec
42 MB
Table 1: Experimental results for bridging faults and circuit indus1 Method Transistor Transistor, No Drop Potential Dominance
Detected 5.1 9.5
Potentially Detected 92.0 72.3
89.8
5.8
Dropped due to Loop Hyper Active 1.5 0 1.5 15.3 1.1
0
Undetected 1.5 1.5 3.3
Ressources CPU Time Memory 8476 sec 284 MB 98 hours 377 MB 7883 sec
257 MB
Table 2: Experimental results for bridging faults and circuit indus2 Pulse, ns 1 5 10 40 50 100 1000 5000 10000
# Faults 1040 1040 1040 1040 1040 1040 1040 1040 1040
Undetectable 0 0 0 0 0 0 0 0 0
Potential abs % 62 6.0 63 6.1 62 6.0 160 15.4 150 14.4 139 13.4 201 19.3 187 18.0 178 17.1
Undetected abs % 684 65.8 681 65.5 666 64.0 269 25.9 184 17.7 163 15.7 96 9.2 74 7.1 62 6.0
Detected abs % 289 27.8 291 28.0 307 29.5 606 58.3 701 67.4 733 70.5 738 71.0 776 74.6 797 76.6
Else abs % 5 0.5 5 0.5 5 0.5 5 0.5 5 0.5 5 0.5 5 0.5 3 0.3 3 0.3
Simul. time, s 11806.8 9074.3 7193.8 3957.8 3852.9 3411.3 3339.2 3033.1 2907.4
Table 3: Experimental results for crosstalk faults and circuit indus3
4 Experimental Results We applied our simulation methodology to three industrial benchmarks which we will refer to as indus1, indus2 and indus3. Block indus1 is a multiplier library cell. Since there is no production test for a library cell, we applied to indus1 an exhaustive test generated by a counter. Block indus2 is a digital cosine wave generator from a full-custom IC, and block indus3 is a data slicer. We applied generated functional patterns to indus2 and indus3. All considered blocks have dynamic logic parts and provide no scan access. Stuck-at coverage of both test patterns with respect to full Verifault fault set is in the 90s, respectively. The realistic bridging and crosstalk fault lists were generated from the layout information (however different defect sizes on different layers were assumed for the two blocks). The layout-based technique also was implemented to fit into the Micronas design flow. There were 268 faults for indus1 and 137 faults for indus2. The time figures are not directly comparable since the experiments have been performed on two different Sun Ultra compute servers. The results for indus1 can be found in Table 1, the result for indus2 are given in Table 2. We performed three simulations for both ICs: using the Transistor Bridge Model with potentially detected faults dropped from the fault list (1st row), using the Transistor Bridge Model with potentially detected faults kept in the fault list (2nd row) and using the Dominance Bridge Model with potentially detected faults dropped from the fault list (3rd row). In the first col-
umn, the used method is quoted, followed by five columns giving the distribution of faults in the fault list in %. In detail the percentage of detected faults is followed by the percentage of potentially detected faults and percentage of faults dropped from the fault list because they caused loops could not resolve (oscillation) or lead to hyper Verifault activity. The percentage of undetected faults is succeeded by the CPU time required for simulation and its memory consumption. As already mentioned in Section 2.2, most faults can not be classified as detected or undetected using the Transistor Model, both with potentially detected fault dropping switched on and off. More CPU time and machine’s memory is spent by the Transistor Model simulation, especially if potentially detected faults, which constitute the largest part of the fault list, are not dropped. Table 3 quotes the results for indus3 and the Crosstalk Model. We excluded all faults where a clock line acts as a victim, since such defects are highly unlikely. For several values of pulse duration in ns (parameter gltime), the distribution of faults is reported. The clock cycle has the duration of 50 ns. The duration in column 1 is followed by overall number of faults, number of faults proven undetectable, and the distribution of detectable faults. For each class, both absolute and percental values are given. The last column contains the simulation time in CPU s. As can be expected, the fault coverage increases with growing pulse duration, and simulation time decreases due to the fact that more faults are dropped early.
5 Conclusions We tackled the problem of simulation of realistic bridging and crosstalk faults generated from layout within the framework for Defect-Based Testing currently being developed by Micronas and the University of Freiburg. There were many good reasons to use the Cadence Verifault tool and not an university tool for the simulation. To be able to handle bridging and crosstalk faults, however, we developed and evaluated different methods of reducing these faults to stuck-at faults in Verifault . The crosstalk model we presented is parameterizable in terms of pulse duration. Furthermore, it can be easily adapted to describe multiple-agressor or multiple-victim situations. Comparing two proposed bridging fault models, we found a bridging fault model formulated at HDL level superior to a transistor-based model at gate level with respect to both accuracy and performance. The model described in the paper assumes the ‘dominance’ behaviour of the bridge. However, modeling of any other bridge behaviour is possible at HDL level (in contrast to the transistor model, which depends on built-in functionality of pre-defined Verilog transistor primitives). To exploit this flexibility for modeling real defects will be the main focus of our research in the future. Further open questions are the distribution of aggressor and victim roles if more than two wires are involved and the realistic duration of crosstalk pulse.
6 References [1] M. Abramovici, M.A. Breuer, and A.D. Friedman. Digital Systems Testing and Testable Design. Computer Science Press, 1990. [2] R.C. Aitken. Finding defects with fault models. In Int’l Test Conf., pages 498 – 505, 1995. [3] Prithviraj Banerjee and Jacob A. Abraham. A multivalued algebra for modeling physical failures in MOS VLSI circuits. IEEE Trans. on CAD, 4(5):312–321, 1985. [4] F. Celeiro, L. Dias, J. Ferreira, M. B. Santos, and J. B. Teixeira. VHDL fault simulation for defect-oriented test and diagnosis of digital ICs. In European Conf. on Design Automation, pages 450–455, 1996. [5] F. Celeiro, L. Dias, J. Ferreira, M. B. Santos, and J. P. Teixeira. Defectoriented IC test and diagnosis using VHDL fault simulation. In Int’l Test Conf., pages 620–628, 1996. [6] W.Y. Chen, S.K. Gupta, and M.A. Breuer. Test generation for crosstalk-induced faults: Framework and combinational results. In Asian Test Symp., 2000. [7] F. Corsi, C. Marzocca, and S. Martino. Assessing the quality level of digital CMOS IC’s under the hypothesis of non-uniform distribution of fault probabilities. In European Design & Test Conf., pages 72–78, 1996. [8] P. Dahlgren and P. Liden. A fault model for switch-level simulation of gate-to-drain shorts. In VLSI Test Symp., pages 414–421, 1996. [9] J. P. de Gyvez and J. A. G. Jess. On the definition of critical areas for IC photolitographic spot defects. In European Test Conf., pages 152–158, 1989. [10] C. Di and J. Jess. On accurate modeling and efficient simulation of CMOS opens. In Int’l Test Conf., pages 875–882, 1993. [11] Chennian Di and Jochen A.G. Jess. An efficient CMOS bridging fault simulator: With SPICE accuracy. IEEE Trans. on CAD, 15(9):1071– 1080, 1996. [12] M. Favalli, P. Olivo, and B. Ricco. A probabilistic fault model for analog faults. In European Conf. on Design Automation, pages 85– 88, 1991.
[13] Michele Favalli, P. Olivo, and Bruno Ricc`o. A probabilistic fault model for ”analog” faults in digital CMOS circuits. IEEE Trans. on CAD, 11(11):1459–1462, 1992. [14] F. Joel Ferguson and J. Shen. Extraction and simulation of realistic CMOS faults using inductive fault analysis. In Int’l Test Conf., pages 475–484, 1998. [15] G.S. Greenstein and J.H. Patel. E-PROOFS: a CMOS bridging fault simulator. In Int’l Conf. on CAD, pages 268–271, 1992. [16] E. Jenn, J. Arlat, M. Rimen, J. Ohlsson, and J. Karlsson. Fault injection into VHDL models: The MEFISTO tool. In Int’l Symp. on Fault-Tolerant Comp., pages 66–75, 1994. [17] W. Ke and P.R. Menon. Synthesis of delay-verifiable combinational circuits. IEEE Trans. on Comp., 44(2):213–222, 1995. [18] J. Khare and W. Maly. Inductive contamination analysis (ICA) with SRAM application. In Int’l Test Conf., pages 552–560, 1995. [19] J. Khare and W. Maly. From contamination to defects, faults and yield loss. Kluwer Academic Publisher, 1996. [20] J. Khare, W. Maly, and N. Tiday. Fault characterization of standard cell libraries using inductive contamination analysis (ICA). In VLSI Test Symp., pages 405–413, 1996. [21] R. Kundu and R. D. Blanton. Identification of crosstalk switch failures in domino cmos circuits. In Int’l Test Conf., pages 502–509, 2000. [22] A. Lechner, M. Burbidge, A. Richardson, and B. Hermes. 3DB challenge for DfT, DfM, DOT & BIST integration into analogue and mixed signal ics. In Latin American Test Workshop, pages 194–199, 2001. [23] U. Mahlstedt and J. Alt. Simulation of non-classical faults on the gate level - the fault simulator COMSIM. In Int’l Test Conf., pages 883– 892, 1993. [24] W. Maly. Realistic fault modeling for VLSI testing. In Design Automation Conf., pages 173–180, 1987. [25] W. Maly, B. Trifilo, R. Hughes, and A. Miller. Yield diagnosis through interpretation of tester data. In Int’l Test Conf., pages 10–20, 1987. [26] P. Maxwell, R. Aitken, and L. Huisman. The effect on quality of nonuniform fault coverage and fault probability. In Int’l Test Conf., pages 739–746, 1994. [27] P.C. Maxwell and R.C. Aitken. Biased voting: A method for simulating CMOS bridging faults in the presence of variable gate logic thresholds. In Int’l Test Conf., pages 63–72, 1993. [28] S.D. Millman and Sir J.P. Garvey. An accurate bridging fault test pattern generator. In Int’l Test Conf., pages 411–418, 1991. [29] S.D. Millman, E.J. McCluskey, and J.K. Acken. Diagnosing CMOS bridging faults with stuck-at fault dictionaries. In Int’l Test Conf., pages 860–870, 1990. [30] I. Polian, P. Engelke, and B. Becker. Efficient bridging fault simulation of sequential circuits based on multi-valued logics. In Int’l Symp. on Multi-Valued Logic, 2002. [31] M. B. Santos and J. P. Teixeira. Defect-oriented mixed-level fault simulation of digital systems-on-a-chip using HDL. In Design, Automation and Test in Europe, 1999. [32] J. Segal and D. Lepeljan. The value of electrical bitmap results for yield learning and failure analysis. In Latin American Test Workshop, pages 260–265, 2001. [33] G. Spiegel and A. Stroele. A unified approach to the extraction of realistic multiple bridging and break faults. In European Conf. on Design Automation, pages 184–189, 1995. [34] C. Stapper. Modeling of integrated circuit defect sensitivities. IBM J. Res. and Develop., 27:549–557, 1983. [35] O. Stern and H. Wunderlich. Simulation results of an efficient defect analysis procedure. In Int’l Test Conf., pages 729–738, 1994. [36] C. Strolenberg. Stay away from minimum design-rule values. In Design, Automation and Test in Europe, pages 71–72, 2000. [37] S. Zachariah and S. Chakravarty. A scalable and efficient methodology to extract two node bridges from large industrial circuits. In Int’l Test Conf., 2000. [38] S. Zachariah, S. Chakravarty, and C. Roth. A novel algorithm to extract two-node bridges. In Design Automation Conf., 2000. [39] Y. Zhao and S. Dey. Analysis of interconnect crosstalk defect coverage of test sets. In Int’l Test Conf., 2000.
