Download as ps, pdf, or txt
Download as ps, pdf, or txt
You are on page 1of 14

The Nemesis User's Manual

Craig Hall Brian Chess Tracy Larrabee Computer Engineering University of California, Santa Cruz 95064

1 Introduction
Welcome to Nemesis. Nemesis is a diverse program that simulates and generates test patterns for circuits with a variety of di erent types of faults. Nemesis generates tests for stuck-at and bridgeIDDQ faults in combinational circuits and simulates tests for stuck-at, bridge, and bridgeIDDQ faults in combinational circuits. In addition, Nemesis simulates tests for stuck-at and bridgeIDDQ faults in sequential circuits. The test patterns which Nemesis generates are done using the Boolean satis ability method Lar92]. This is the Nemesis User's Manual. It is designed to quickly and e ectively allow users to exploit the features available in Nemesis. Much of the detailed information concerning actual design and implementation has been left to more technically oriented papers FTL90, FL91b, FL91a, CL93, CL94]. This manual includes:

contains suggestions for resolving any errors encountered while running Nemesis. Appendixes: Explanations of the various formats that Nemesis supports (including test formats, circuit formats, and faultlist formats). Nemesis is the product of the dedicated e orts of many people at the University of California, Santa Cruz. Nemesis' development was guided by Associate Professor Tracy Larrabee and relies upon her Boolean satis ability method of generating test patterns. The overall design and a large portion of the implementation was done by Brian Chess. This work was sponsored by NSF under MIP-9158490 and MIP 9158491, SRC under 93-05-315, and by gifts from Intel and Motorola.

De nitions: A quick reference for basic terms used throughout the Nemesis manual. Installation: A step by step procedure for installing Nemesis. Tutorial: A brief tutorial on how to put Nemesis to immediate use. Running Nemesis: A guide to the options supported by Nemesis. TroubleShooting: A section that will no doubt grow as our user base does, TroubleShooting

Acknowledgements

2 De nitions

test for that fault exists. There are many existing test pattern generation systems FS83, Goe81, Rot66, STS88]. Test Simulation Test simulation is the process of simulating a potential test against a list of faults. Nemesis uses parallel fault simulation a la PROOFS NCP92]. 1

Test Generation Test generation is the process of nding a test for a fault or showing that no

line were permanently tied to a logic 1 or logic 0 instead of varying as a function of the circuit inputs. Bridge Fault: A bridge fault is a short between two signal wires in the circuit which are interconnected with a logical behavior speci ed by a PTbridge tta le FL91b]. There are several existing test pattern generation systems that produce tests for bridge faults CL93, CL94, MG91, RP93, MA93]. BridgeIDDQ Test: For a bridge fault, any test that causes the two bridged wires to take on opposite logic values in the fault free circuit is an IDDQ test for that fault FL91a]. Logical Test: A logical test for a fault creates a discrepancy between the primary circuit output in the presence of the fault and the primary circuit output in the absence of the fault. IDDQ Test: An IDDQ test for a fault causes the circuit to draw excessive quiescent current in the presence of the fault FTL90]. Test Compaction: Test compaction is the process of reducing the size of a test set without decreasing the fault coverage of the set.

Stuck-At Fault: A stuck-at fault is an abstraction wherein the faulty circuit behaves as if one

3 Installation
Nemesis has been compiled on a variety of UNIX platforms and is available through anonymous ftp as a compressed binary from ftp.cse.ucsc.edu in the directory /pub/nemesis. The postscript version of this manual, manual.ps, is also available in the /pub/nemesis directory. In addition to the Nemesis binary speci c to your architecture (Nemesis.arch.Z) you will need the compressed Nemesis tar le available in the same directory (Nemesis.tar.Z), which includes input les necessary to run all versions of Nemesis. The same les can be found at the site http://sctest.cse.ucsc.edu/nemesis/nemesis.html. Nemesis binaries exist for the Sun-4, DEC Alpha, DECstation, and HP precision architectures. The arch replacements for each of these architectures in the tar commands given below are, respectively, sun4, alpha, decstation, and hppa. To install Nemesis, rst move the Nemesis binary to the directory in which Nemesis will be located. Then type the following commands: uncompress Nemesis.arch.Z (expand the Nemesis binary) uncompress Nemesis.tar.Z (uncompress the Nemesis.tar le) mv Nemesis.arch Nemesis (rename your Nemesis binary to Nemesis) tar -xvf Nemesis.tar (execute the Unix tar command) config (update sample con guration les) If Nemesis is to be run outside of the directory where it is located, add the directory where Nemesis is stored to your PATH environment variable. Nemesis is now installed and ready to run.

4 Tutorial
This chapter contains a typical Nemesis test pattern generation session. It is provided to give a rst time user a quick overview on how to get Nemesis running. This tutorial is based on a session run on a DEC Alpha 3000/600 running OSF 2.0. For ease of use, the command line arguments for Nemesis are optional. As a result, Nemesis uses a con guration le to obtain the other information necessary to run. The default location for this le is the current directory where you are running Nemesis. Since it can be cumbersome to have 2

4.1 Nemesis requirements

a con guration le in every directory from which Nemesis is run, the le may also be set up as an environment variable, NEMESIS CONFIG. To maintain simplicity during the tutorial, con guration le creation is discussed in Chaper 5, Running Nemesis. However, the con guration le does need to be established before Nemesis will work. For the tutorial, we will use sample con guration les provided in the Nemesis/lib/config directory. An optional alternative to the con g le is command line ags. For more information on this, see Section 5.1. Once a con guration le has been established, Nemesis is ready to be run. Since the circuit name is an optional con guration speci cation, and the only command line argument that Nemesis accepts (see Section 5.1), it can be entered on the command line:
% Nemesis c432 c432

4.1.1 Test Pattern Generation for Stuck-AT faults on the combinational circuit c432.

speci es that the combinational circuit c432 is to be used. The following is the stdout output caused by running Nemesis with default.config on c432. (default.con g is one of the example con g les included in your Nemesis package.)
writing log to Nemesis.log reading config file /projects/vlsi/sctest/lib/Nemesis/config/default.config loading circuit c432 reading stuck-at fault list generating random tests 520 faults detected with 83 tests learning circuit learned 85 items generating tests targeting output pin 0 of nand2_17 stuck at 1: proved untestable (bt: 54) targeting output pin 0 of nand2_44 stuck at 1: proved untestable (bt: 38) targeting input pin 1 of nand4_10 stuck at 1: proved untestable (bt: 0) targeting output pin 0 of nand2_62 stuck at 1: proved untestable (bt: 71) backtrack profile: 0 1-10 10-100 100-300 300+ failed xxxx: 1 3 0 faults detected with 0 tests 520 detected faults 4 faults proved undetectable 00:00:00.983 CPU time, 00:00:01.476 Real time (total)

These results are written to Nemesis.log as well as stdout. A complete explanation of the Nemesis.log le is included in Section 5.4.

5 Running Nemesis
This section contains a thorough explanation of the con gurations available for running Nemesis, as well as a description and analysis guide of the output les Nemesis creates.

5.1 Command Line

In order to quickly change or override options that are in the con g les, Nemesis accepts command line ags. The format for running Nemesis with a ag included is: 3

% Nemesis

- ag value circuit name

ag can be any of the con gurations listed in Section 5.3. value is of con guration type true/false, string, or integer and determines the value of flag (for example, Nemesis -do stuck-at 1 c432 sets do stuck-at to 1 and runs the circuit c432.tdl). circuit name is the only command line argument that Nemesis accepts, and it is optional. The name of the circuit which Nemesis will run can also be speci ed by use of the ag -circuit name, or by entering it directly into the con g le (e.g., circuit name = c432). Nemesis ags o er a quick alternative to constantly editing the con guration le. Since a virtually unlimited number of ags can be entered (subject to the limits of the operating system), all of the con guration options necessary to run Nemesis can conceivably be set on the command line.

5.2 Con guration Files

To specify the information necessary for Nemesis to run, either create a con guration le customized to your needs or use one of the samples provided. When editing or creating con guration les the con guration le must contain at a minimum the following con gurations: Simulate or generate tests. Fault type to run on. Root directory. Circuit directory. Faultlist directory. Test directory. Cell library. For bridge faults, a truth table directory. If circuit name is not given on the command line, a circuit name. In the example below, Nemesis is not running on bridge faults, so no truth table directory is listed, and it is assumed that the circuit name is given on the command line, so no circuit name is given. See Section 5.3 for the syntax of the con gurations.

generate_tests = 1 do_stuck-at = 1 root_dir = /projects/vlsi/sctest/data/Nemesis circuit_dir = circuits/ISCAS85/ISCAS stuck-at_faultlist_dir = faultlists/ISCAS85/ISCAS/stuckat test_dir = tests/ISCAS85/ISCAS/stuckat cell_lib = ISCAS

There are additional commands that may be included in the con guration le (such as print tests), but only the con gurations mentioned above are necessary. In the case where multiple options are speci ed at once (for example: do stuck-at and do bridge both set to 1) both options are implemented. In the case where the same con guration setting is repeated, whether repeated within a le or in both the Nemesis.config le and the le set to NEMESIS CONFIG, the rst appearance is used. Note that Nemesis will read the command line ags rst, then the local con g le, and nally the default le speci ed by NEMESIS CONFIG. If any con guration options 4

included in the default con g le are not mentioned in the local Nemesis.con g or on the command line, the options in the default le will still be used. In other words, make sure to override any unwanted options that are in the NEMESIS CONFIG le, either by entering them in the local le or using a ag (see Section 5.1). Several commands require the inclusion of other con gurations, and an error will occur if they are omitted; these are discussed in Section 5.3. There are three types of con gurations: true/false, strings, and integers. True/False con gurations are options which are turned on by setting the option to 1, and turned o by setting the option to 0 (true and false also work). Con gurations are of string type when a speci c item is being named, such as a directory or a circuit name. An integer con guration is a number that can be set within some integer range. The comment character in a con guration le is #. Anything following a # character on a line is ignored by Nemesis. Similarly, if a con guration which is included in the le does not exist, Nemesis ignores it. The order in which con gurations are entered in the le does not e ect Nemesis' execution. The Nemesis.log le, which Nemesis produces during execution, will contain a complete listing of the con gurations Nemesis used while running.

5.3 Con gurations

or bridgeIDDQ faults for combinational circuits. See the De nitions section for a complete description of test pattern generation. simulate tests true/false: Turns test simulation on or o . May be run with any supported fault type for combinational circuits, and with stuck-at, bridge, or bridgeIDDQ faults for sequential circuits. The De nitions section has a complete description of test simulation. (Note: test simulation of bridge faults on sequential circuits is still experimental.) reset before tests 0/1/X: Value to reset the combinational elements in sequential circuits to before appling tests. reset between tests true/faulse: Cause the combinational circuit elements to be reset between each set of tests. generate random tests integer: Sets the number of consecutive non-detecting random test patterns to run before boolean satis ability is applied. This allows Nemesis to remove some of the burden from the generator. The generate random tests option is turned o when set to 0. Range: 0 - 100,000. random test length integer: Sets the number of patterns for random test on sequential circuits. (Note: in combinational circuits this value will act as a multiplier of the generate random tests value, and must be greater than 0.) Range: 0 - 1,000. do stuck-at true/false: Makes stuck-at faults testing active. See the De nitions chapter for a complete description of stuck-at faults. Requires: stuck-at faultlist dir. do tso true/false: Makes testing of transistor stuck on faults active. Requires: tso faultlist dir. do cshort true/false: Makes cshort faults testing active. Requires: cshort ftt dir. do bridge true/false: Makes logical testing of bridge faults active. See the De nitions chapter for a complete description of bridge faults and logical testing. Requires: bridge faultlist dir, bridge tta dir. do bridgeIDDQ true/false: Makes IDDQ testing of bridge faults active. See the De nitions chapter for a complete description of bridge faults and IDDQ testing. Requires: bridge faultlist dir. 5

generate tests true/false: Turns test pattern generation on or o . May be run with stuck at

urations. The default for root dir, if no value is entered, is the current directory. circuit dir string: The directory containing the circuit les to be used by Nemesis. See Appendix ?? for a complete description of the tdl format. circuit name string: The name of the circuit upon which Nemesis will run. May either be speci ed here or on the command line. Do not include the .tdl su x when naming a circuit. cell lib string: Speci es the cell library used to open the circuit. This is necessary as MCNC and ISCAS have di erent formats for cell names. As of this release, cell lib must either be ISCAS or MCNC. test dir string: The directory containing test les to be used by Nemesis when simulating tests. See Appendix ?? for a complete description of the test format. stuck-at faultlist dir string: The directory containing the faultlists to be used by Nemesis when testing for stuck-at faults is active. For a complete description of the faultlist le format, please see Appendix ??. tso faultlist dir string: The directory containing the faultlists to be used by Nemesis when testing for transistor stuck on faults is active. cshort ftt dir string: The directory containing the cshort tables to be used when testing for cshort faults is active. bridge faultlist dir string: The directory containing the faultlists to be used by Nemesis when testing for bridge faults (logical/IDDQ testing) is active. Files are in hierarchical Carafe format. Carafe is fully described by Ferguson and Jee Jee91, JF93b, JF93a]. Also see the Appendixes for a complete description of hierarchical Carafe format. bridge tta dir string: The directory containing truth tables for fault blocks. See the De nitions chapter for a complete description of logical testing for bridge faults. Appendix ?? goes through the truth table le format. compact tests true/false: Turns test compaction on and o . Test compaction is explained in the De nitions chapter. print simulator true/false: Turns on or o the creation of the netLabels.%d les, where %d is an integer which increases with each netValue le. Appendix ?? explains the netValue le format and gives some warnings about its use. print detected true/false: Turns on or o the creation of the circuit name.detected le in the current directory. print undetected true/false: Turns on or o the creation of the circuit name.undetected le in the current directory. print formulas true/false: Turns on or o the creation of the formula.#, formula.faultfree, and variable.map les in the current directory. This con guration was implemented for debugging purposes. print tests true/false: Turns on or o the creation of the circuit name.tests le in the current directory. print stuck-at faultlist true/false: Turns on or o the creation of the circuit name.faultlist le in the current directory. More information on the les created by the print con gurations listed above can be found in the next section on Output Files. 6

root dir string: The path name that will be concatenated in front of all other directory con g-

5.4 Output Files

Nemesis.Log Nemesis.log is an output le created by the initial run of Nemesis and written to the

directory you are running Nemesis from. Every successive time Nemesis is run, the results are appended to the Nemesis.log le. The following sample log is output created from running Nemesis with default.config and the c432 circuit.

## Nemesis log file # Created by Nemesis # running on ren which is a alpha running OSF1 release V3.2 # Run Date: Tue Oct 3 16:00:09 1995 # Compile Date: Sep 19 1995 -------------------------------------------------------command line: c432 -------------------------------------------------------reading config files opening /projects/vlsi/sctest/lib/Nemesis/config/default.config do_stuck-at = 1 cell_lib = ISCAS generate_random_tests = 100 generate_tests = 1 do_learning = 1 root_dir = /projects/vlsi/sctest/data/Nemesis circuit_dir = circuits/ISCAS85/ISCAS stuck-at_faultlist_dir = faultlists/ISCAS85/ISCAS/stuckat test_dir = tests/ISCAS85/ISCAS/stuckat -------------------------------------------------------reading circuit opening /projects/vlsi/sctest/data/Nemesis/circuits/ISCAS85/ISCAS/c432.tdl with cell library ISCAS 00:00:00.033 CPU time, 00:00:00.930 Real time -------------------------------------------------------reading stuck-at fault list opening /projects/vlsi/sctest/data/Nemesis /faultlists/ISCAS85/ISCAS/stuckat/c432 .faultlist got 524 faults -------------------------------------------------------generating random tests random test cutoff number: 100 random test length: 1 520 faults detected with 83 tests 552 tests simulated 00:00:00.502 CPU time, 00:00:00.636 Real time -------------------------------------------------------learning circuit 85 learned items 00:00:00.229 CPU time, 00:00:00.388 Real time -------------------------------------------------------generating tests backtrack limit: 600 0 faults detected with 0 tests

00:00:00.177 CPU time, 00:00:00.000 Real time -------------------------------------------------------520 detected faults 4 faults proved undetectable -------------------------------------------------------00:00:00.983 CPU time, 00:00:01.476 Real time (total)

The information in the rst section informs you that this is a Nemesis log le, when and where your version of Nemesis was compiled, and the date Nemesis was run. The next section shows you the command line arguments used to run Nemesis. The section after that shows which con guration les were read and what con gurations they set. The sections which follow give a description of Nemesis' progress and the time it took. The nal two sections list the number of faults and the total elapsed time. Detected The circuit name.detected le contains a list of detected faults. Undetected The circuit name.undetected le contains a list of undetected faults. Formulas Each formula.# le contains a formula used during test generation. The formula is in conjunctive normal form, where a + represents an or, a - represents a not, and each line is anded. The integer appearing on the rst line is the highest variable appearing in the formula. The formula is used as debugging information during development. formula.faultFree The formula.faultFree le contains the formula representing the fault free circuit. variable.map The variable.map le contains a listing of variable names as they correspond to actual net names. In the following excerpt, w432gat is the actual wire name which is mapped as 170, 171, 172, and 173 in the corresponding formulas. (e.g., 170 would represent w432gat in the formula.faultfree le.)
w432gat: fault free 170 faulty 171 active 172 extra 173

Tests The circuit name.tests le contains test pattern information generated by Nemesis. This
information is of the form:
1 pattern test input: 11010 output: 11

where the rst line gives the number of patterns (1 in combinational circuits). The input and output values (in this case 11010 and 11) are assigned to input and output pins in the same order as they appear in the tdl le. Nemesis may use output test les as input test les for test simulation. netLabels The netLabels.%d les give the state of the simulator for a speci c targeted fault and simulated fault. The le lists all the nets in the circuit. Beside each net name is the fault free value for the wire and the value on the wire when the given fault is active. These two values are separated by a backslash (/). If only one value is given, the fault free and faulty values for that instance were the same. Faultlist The circuit name.faultlist le contains a list of all the stuck-at faults which need to be tested for the circuit. 8

6 TroubleShooting
Most errors while running Nemesis are caused by errors in the con guration le. The quickest way to resolve these errors is to carefully examine the section in the Nemesis.log le which shows what con guration le was used and the con gurations in that le. Con gurations that are thought to be set in the le but do not appear in Nemesis.log contain an error which is preventing Nemesis from understanding them (i.e. a misspelling).

Note: Nemesis is shipped with no known bugs. Should any problems be discovered, please send
mail to NemesisBugs@cse.ucsc.edu.

References
BBK89] F. Brglez, D. Bryan, and K. Kozminski. Combinational pro les of sequential circuit benchmarks. In Proceedings of the IEEE International Symposium on Circuits and Systems, 1989. BF85] F. Brglez and H. Fujiwara. A neutral netlist of 10 combinational benchmark circuits and a target translator in fortran. In Proceedings of the IEEE International Symposium on Circuits and Systems, 1985. CL93] B. Chess and T. Larrabee. Bridge fault simulation strategies for cmos integrated circuits. In Proceedings of Design Automation Conference, pages 458{462, 1993. CL94] B. Chess and T. Larrabee. Generating test patterns for bridge faults in CMOS ICs. In Proceedings of European Test Conference, 1994. FL91a] F. J. Ferguson and T. Larrabee. Test pattern generation for current testable faults in static CMOS circuits. In Proceedings of the 1991 VLSI Test Symposium, pages 297{302. IEEE, 1991. FL91b] F. J. Ferguson and T. Larrabee. Test pattern generation for realistic bridge faults in CMOS ICs. In Proceedings of International Test Conference, pages 492{499. IEEE, 1991. FS83] H. Fujiwara and T. Shimono. On the acceleration of test-generation algorithms. IEEE Transactions on Computers, C-32(12):1137{1144, December 1983. FTL90] F. J. Ferguson, M. Taylor, and T. Larrabee. Testing for parametric faults in static CMOS circuits. In Proceedings of International Test Conference, pages 436{443. IEEE, 1990. Goe81] P. Goel. An implicit enumeration algorithm to generate tests for combinational logic circuits. IEEE Transactions on Computers, C-30:215{222, March 1981. Jee91] A. Jee. Carafe user's manual. Technical Report UCSC-CRL-90-61, University of California at Santa Cruz, Computer Engineering Department, February 1991. JF93a] A. Jee and F. J. Ferguson. Carafe: A software tool for failure analysis. In Proceedings of International Symposium for Testing and Fault Analysis, pages 143{149, 1993. JF93b] A. Jee and F. Joel Ferguson. Carafe: An inductive fault analysis tool for CMOS VLSI circuits. In Proceedings of the IEEE VLSI Test Symposium, pages 92{98, 1993. Lar92] T. Larrabee. Test pattern generation using boolean satis ability. IEEE Transactions on Computer-Aided Design, pages 4{15, January 1992. MA93] P. Maxwell and R.C. Aitken. Biased voting: a method for simulating CMOS bridging faults in the presence of variable gate logic thresholds. In Proceedings of International Test Conference, pages 63{72. IEEE, 1993. 9

MG91] S.D. Millman and J.P. Garvey. An accurate bridging fault test pattern generator. In Proceedings of International Test Conference, pages 411{418. IEEE, 1991. NCP92] T. Niermann, W.-T. Cheng, and J. Patel. Proofs: A fast, memory-e cient sequential circuit fault simulator. IEEE Transactions on Computer-Aided Design, pages 198{207, 1992. Rot66] J. P. Roth. Diagnosis of automata failures: A calculus and a method. IBM Journal of Research and Development, 10:278{291, 1966. RP93] J. Rearick and J. Patel. Fast and accurate CMOS bridging fault simulation. In Proceedings of International Test Conference, pages 54{62. IEEE, 1993. STS88] M.H. Schulz, E. Trischler, and T.M. Sarfert. SOCRATES: a highly e cient ATPG system. IEEE Transactions on Computer-Aided Design, CAD-7(1):126{137, January 1988.

10

Appendixes A
.tdl

File Format

Purpose
The .tdl le is the gate level netlist description of the fault free circuit which Hemlock outputs. The le's output, generated by the Hemlock version of Carafe, is derived from the Tegas Description Language le format.

Description
This le begins with a line giving the module name, normally the name of the circuit le. The INPUTS and OUTPUTS sections list the primary inputs and the outputs of the circuit. The DESCRIPTION line contains information about the le such as the date and that it was created by Carafe of Hemlock. The next line is the USE line and is for future usage. The DEFINE section contains the list of the cells in the form output instance = input instance. Figure ?? shows the gate represented by the rst line following the de ne : aoi21s 0(q=I7) = aoi21s(a1=I10,a2=I7gat,b=I13);.

Example
MODULE : C 17; INPUTS : I1gat, I2gat, I3gat, I6gat, I7gat; OUTPUTS : I22gat, I23gat; DESCRIPTION : TDL file created by Carafe of Hemlock on Fri Feb 22 14:23:26 1991 USE : DEFINE : aoi21s_0(q=I7) = aoi21s(a1=I10,a2=I7gat,b=I13); ai2s_3(q=I10) = ai2s(a=I3gat,b=I6gat); ai2s_2(q=I22gat) = ai2s(a=I8,b=I12); i1s_1(q=I23gat) = i1s(a=I7); i1s_0(q=I13) = i1s(a=I12); ai2s_1(q=I12) = ai2s(a=I2gat,b=I10); ai2s_0(q=I8) = ai2s(a=I1gat,b=I3gat); END : MODULE;

11

I10 I7gat I13

a1 a2 b

TYPE: aoi21s NAME: aoi21s_0 q I7

Figure 1: The test pattern generation system for shorts within standard cells

B .faultlist
Nemesis uses faultlist les to determine what faults to look for when simulating or generating tests. The two formats used for faultlists are bridge and stuck-at. As usual the # is a comment indicator. The format for declaring a stuck-at fault is: primary input netname stuck at 1 or 0 or input or output pin pinNumber of cellName cellNumber stuck at 1 or 0 The following are excerpts from sample faultlists.
primary input w1gat stuck at 1 input pin 0 of nand2_1 stuck at 1 primary input I3gat stuck at 0 output pin 0 of ai2s_3 stuck at 0 # ISCAS net name # ISCAS cell name # MCNC net name # MCNC cell name

The format for declaring a bridge fault is: cellName1 cellName2 netName1 netName2 weighted critical area cellName1 and cellName2 represent the cells driving the bridged wires. The cell names can each be given as either an MCNC cell name or, if the wire is driven by a primary input, as input. netName1 and netName2 give the names of the bridged wires. The following are some examples:
input_input I2gat I1gat 15469.111 i1s_input I23gat I1gat 300704.375 ai2s_ai2s I22gat I8 106387.391 # a bridge between two inputs # a bridge between an inverter and an input # a bridge between two nand gates

The faultlists included with this release of Nemesis are sample faultlists for these benchmark circuits. In future releases a standard faultlist will be established. The bridge faultlists were created by hierarchical Carafe.

C .tta
Truth table les are necessary to give a more accurate representation of what occurs at a bridge fault site. There are tta les for all MCNC cell bridge faults. These les were created by PTbridge. The format is as follows: .i number of inputs .o number of outputs inputs d digital value or inputs a analog value

inputs is a string of 0s and 1s which can be assigned to the input pins of the two cells between which the bridging fault occurs. inputs followed by a d indicates that a digital value well beyond the threshold is the output. When inputs is followed by an a an analog value is the output. The following is an excerpt from ai3s oi3s.tta, a le containing the truth table for a bridge between the outputs of a 3 input NAND and a three input NOR.

.end

12

# a comment .i 6 .o 1 000000 d 1 000001 a 4.251169e+00

D .tests
Nemesis communicates test information in the test format. This format is used for output test les when Nemesis is generating tests, and for input test les when Nemesis is simulating tests. As a result, Nemesis may simulate tests that it has generated. The following is an excerpt from a sample test le.
# a comment 1 pattern test input: 11010 output: 11 1 pattern test input: 10001 output: 01

As usual, any line beginning with a # is a comment. The number of inputs and outputs must equal the number of inputs and outputs of the circuit you're trying to feed the tests in to. The output: directive is optional. You could specify the same tests like this:
# a comment 1 pattern test input: 11010 1 pattern test input: 10001

if no output: directive is given, there must be a separator line between tests.

E netLabels.%d
Each netLabels le records the state of the simulator as it was while targetting and simulating a stuck-at fault. The targeted fault and simulated fault are given in the rst two lines of the le. The rest of the le is a list of all the nets in the circuit. Each line consists of the net name followed by its fault free value and the value on the wire when the simulated fault is active. The fault free value is separated from the faulty value by a /; if only one number is given, the two values were equal. 13

The following is an excerpt from a netLabels le which gives the state of the simulator for targeted and simulated faults on input pins of or-inverter gates.
# targeted fault input pin 2 of oi3s_0 stuck at 0 # simulated fault input pin 3 of oi4s_0 stuck at 0 I514 0 m89gat 1 I249 0 I254 1 I583 1/0 I163 0 I487 0 I446 0 I61 0 I570 0 m11gat 1

14

You might also like