Fault Simulator and ATPG for Complex Digital Circuits

VILAB Technical Report

Task 2.2

Fault Simulator and ATPG for Complex Digital Circuits

Eero Ivask, Priidu Paomets, Jaan Raik, Raimund Ubar

Tallinn Technical University

March 2000

Table of Contents1 INTRODUCTION ....................................................................................................................... 3

1.1 INSTALLATION........................................................................................................................ 31.2 SYSTEM OVERVIEW .............................................................................................................. 4

2 CIRCUIT MODEL ...................................................................................................................... 7

2.1 SSBDD REPRESENTATIONS ................................................................................................ 72.2 RT-LEVEL DD REPRESENTATIONS ...................................................................................... 8

3 COMMANDS ............................................................................................................................. 10

3.1 HIERARCHICAL TEST PATTERN GENERATOR ..................................................................... 103.2 SIMULATION-BASED TEST PATTERN GENERATOR............................................................. 113.3 FAULT SIMULATOR .............................................................................................................. 123.4 DESIGN INTERFACE............................................................................................................. 13

EDIF Interface..................................................................................................................... 13Library Generator ................................................................................................................ 15

4. EXPERIMENTAL RESULTS ................................................................................................. 16

APPENDIXES............................................................................................................................... 18

APPENDIX A: SSBDD MODEL FORMAT ..................................................................................... 18APPENDIX B: GENERAL DD MODEL FORMAT ............................................................................ 20APPENDIX C: LIBRARY SOURCE FORMAT................................................................................... 27APPENDIX D: TECHNOLOGY LIBRARY FORMAT ......................................................................... 28APPENDIX E: DESIGN EXAMPLE (RT-LEVEL VHDL).................................................................. 29

1 IntroductionThis report describes the test tools implemented at TTU in the framework ofcurrent project. The tools include design interfaces from EDIF and VHDLformats, a fault simulator and an automatic test pattern generator for sequentialcircuits. The design interfaces are documented in detail in VILAB technical report" Interfaces between Design Tools and Test Generation / Fault Simulation Tools".

The report is organized as follows. In Section 1, the installation of the system isexplained and a general overview of its tools is presented. Section 2 explains thediagnostic model of Decision Diagrams (DD) implemented by the diagnosticstools. In Section 3, command-lines of all the programs are documented, followedby Appendixes for the file formats.

1.1 InstallationIn order to install Tallinn Technical University (TTU) test tools you have to copythe file ttu_9912.tar.gz into the directory where you are to set up the system(refered to as current_directory) and enter the following commands:

gunzip ttu_9912.tar.gz

tar xvf ttu_9912.tar

Directories listed below are created to the TTU test tools installation directory.

doc user documentation.

lib technology libraries for the EDIF design interface.

bin executables of the tools.

Add the following line to your .cshrc file in your home directory:

setenv PATH current_directory/bin:$PATH

Subsequently type

source ~/.cshrc

or log out and log in again.

1.2 System OverviewFigure 1 presents the data flow of Tallinn Technical University gate-level testtools. Numbers in brackets show the sections discussing corresponding topics.

Figure 1 System flow of TTU test tools

Schematic Entry

(Synopsys, Cadence,Mentor Graphics,ViewLogic, etc.)

Technology librarysource (App. C)

EDIF netlist

Library generator (3.4)

Technology library (App. D)

EDIF design interface(3.4)

SSBDD model

(2.1, App. A)

Functional test

patterns

Test generator

(3.2)

Fault simulator

(3.3)

Test patterns; fault coverage

The gate-level tools include an EDIF design interface, fault simulator and asimulation-based test generator for sequential circuits. The design interfaceaccepts a wide subset of EDIF 2.0.0 netlist format, thus providing for a link tomost of the available commercial microelectronics CAD systems, includingSynopsys, Mentor Graphics, Cadence, ViewLogic, etc. Since EDIF netlist formatdoes not include any information about the behavior (Boolean function) of thelibrary components (gates) used, a dedicated technology library generator hasbeen additionally created. It allows the user to specify the function of each librarycomponent in an easy to describe format (See Appendix C). The installation alsoincludes a set of pre-generated technology libraries. In addition the designinterface is capable of, both, reading and generating the ISCAS89 benchmarkformat. Thus, it is suitable for linking the TTU test tools with a variety ofuniversity software. More thorough information about the interface can be foundin VILAB project report "Interfaces between Design Tools and Test Generation /Fault Simulation Tools".

The fault simulator implements an SSBDD-based event-driven fault simulationalgorithm, where faults are being inserted serially, one-by-one. This algorithm isfaster than similar event-driven approach at the gate model, since SSBDDsprovide for a significant speed-up of circuit modeling. The simulation basedATPG calls the above mentioned fault simulation function. The features of thesetools are documented in Sections 3.2 and 3.3.

In addition to the gate-level tools, a hierarchical test generation system has beenimplemented that includes a Register-Transfer Level (RTL) VHDL interface.Detailed information about this interface can be found in the report "Interfacesbetween Design Tools and Test Generation / Fault Simulation Tools".

The hierarchical ATPG uses the following approach. Tests are generated for eachFU of the system separately. Symbolic path for propagating fault through thenetwork of components is activated and corresponding constraints are extracted atthe high level. These constraints are reduced to inputs, input values for the FU arecalculated and gate-level fault simulation is applied to the FU using these values.Subsequently, final test patterns for the whole circuit are compiled.

These test patterns are the input stimuli for the RTL design. However, as the testgeneration implements high-level fault models, we do not know the precise gate-level stuck-at fault coverage of the tests. Therefore, the test patterns have to beconverted to correspond to the stimuli for the gate-level netlist of the entiredesign. This is required for gate-level stuck at fault simulation of the design inorder to measure the quality of generated tests.

Figure 2 presents the data flow of TTU hierarchical test pattern generation tools.

Figure 2 Data flow of hierarchical test tools

2 Circuit Model2.1 SSBDD Representations

Figure 3 Combinational Circuit and Its SSBDD

SSBDD models for combinational circuits can be synthesized by a simplesuperposition procedure. We generate an SSBDD for a circuit output by, startingfrom the output, substituting recursively all the gates by their respectiveelementary BDDs until primary inputs are reached. In order to avoid repetitiveoccurences of subgraphs in the model, the recursion is terminated in fanout stemsand SSBDDs can be synthesized for each primary output and fanout pointseparately. In that case the circuit will be described as a system where for eachfanout-free region an SSBDD corresponds.

As an example, Figure 3 shows an SSBDD representation of a combinationalcircuit. For simplicity, values of variables on branches are omitted (by convention,the rightward branch corresponds to 1 and the downward branch to 0). In addition,terminal nodes with constants 0 and 1 are omitted (exiting the SSBDD rightwardscorresponds to y = 1, and downwards to y = 0). The diagram contains 6 nodeswhereas each of them represents a signal path in the circuit. The node labels in theSSBDD correspond to input branches of the circuit shown in Figure 3.

The worst case complexity of SSBDD synthesis by the superposition procedure islinear in respect to the number of logic gates in the model and is therefore fasteven for very large circuits.

2.2 RT-Level DD Representations

Figure 4 DD model of a datapath fragment

At the RT-level, the design is partitioned into a datapath and a control part. Atpresent, we assume that all the functional units are combinational and that single-clocked circuits are considered.

Datapath can be represented by a system of DDs, where for each primary output,fanout signal and register a DD corresponds. In addition, multi-plexers that areconnected to an input of an FU are repre-sented by a separate DD. In datapath DDmodels, the non-ter-minal nodes cor-respond to control signals (e.g. multiplexeraddresses and register enable signals) and terminal nodes represent operations.Register transfers and constant assignments are treated as special cases ofoperations. Values of the control signals labeling the nonterminal nodes of the DDactivate the main path that determines, which opera-tion is assigned to the variablewhose value is calculated by that DD. Figure 4 shows an example of a DDrepresentation for a datapath register.

Control part of an RTL is represented by a DD that calculates the values for avector consisting of the state variable and control signals. In the DD, the non-terminal nodes correspond to current state and conditions (FSM inputs) and termi-nal nodes hold vectors with the values of next state and control signals (FSMoutputs). Figure 5 shows an example of a fragment of an FSM state table and thecorresponding DD representation. In the DD, q denotes the next state and q’denotes the current state value. Variables out1, out2, out3 and out4 are outputsignals of the FSM. The DD in Figure 5 describes the behavior of the FSM whenthe current state is equal to s5.

Figure 5 Converting a state table to a DD

As it was mentioned above, each node in the RT-level DD model has a strongrelation to the structure of the circuit. Generating a test for a given node meanscreating a test for the related structural part of the module or subnetwork.

3 Commands3.1 Hierarchical Test Pattern Generator

command: rtl_gen

Hierarchical test pattern generator for sequential circuits described on RTL(VHDL) and gate (EDIF) levels.

input: RTL DD model file of the design (.agm). SSBDD model files for high-level primitives (*.agm)

output: test pattern file (.tst)

syntax: rtl_gen [options] <design>

design: Name of the design file without .agmextension.

options:

-sequence_length <seq> seq is the number of vectors in each testsequence. Default is 128.

-max_simulations <max> Maximal number of simulated sequences.Default is 1000.

-reset_index <index> Index of the primary input variablecorresponding to global reset in the SSBDDmodel.

-fault_simulate Perform fault simulation for the finalpatterns.

3.2 Simulation-Based Test Pattern Generator

command: sbgen

Simulation based test generator for sequential circuits.

input: SSBDD model file (.agm)


syntax: sbgen [options] <design>


options:

-sequence_length <seq> seq is the number of vectors in each testsequence. Default is 128.

-max_simulations <max> Maximal number of simulated sequences.Default is 1000.

-reset_index <index> Index of the primary input variablecorresponding to global reset in the SSBDDmodel.

-fault_simulate Perform fault simulation for the finalpatterns.

3.3 Fault Simulator

command: fsim

Stuck-at fault simulator for sequential circuits.

input: SSBDD model file (.agm), test pattern file (.tst)


syntax: fsim [options] <design>


options:

-fault_free Perform fault-free simulation.

-extension <extension> extension is the file name extension of thetest pattern file. Default extension is tst.

3.4 Design Interface

EDIF Interface

command: import

Converts EDIF 2.0.0 netlists into SSBDD, ISCAS’85 or ISCAS’89 format.

input: EDIF netlist file, technology library file

output: SSBDD model file (.agm) or ISCAS model file (.cir)

syntax: import [options] <EDIF file> <library file>

options:

-iscas89 Generate ISCAS’89 format.

-tool <application> Options for application are orcad andcadence.

-clock <clock_input> clock_input is the name of the clock input.

-gnd <gnd_name> gnd_name is the name of the GND net.

-vdd <vdd_name> vdd_name is the name of the VDD net.

Error Conditions

The EDIF interface displays error messages and warnings about possible failureswhile parsing the EDIF file or technology library. Line numbers where errorsoccurred are included. Note that some of the warnings should be ignored. Forexample, one of the most common warnings is as follows:

Design: COMPONENT_1

Parsing macro

Warning at line 1917: Gate not in library

This warning shows that there is a cell named COMPONENT_1 in the EDIFdiscription. It means either that COMPONENT_1 is a block in the hierarchy, or itis a cell, which is not specified in the technology library. If the first statement istrue, the warning should be ignored. In the latter case, EDIF parsing fails due toan incomplete technology library. Please pay attention to ALL of the displayederrors and warnings if the program terminates abnormally!

Library Generator

command: libgen

Generates user-specified technology libraries for the EDIF interface.

input: library source file (See ‘Library Source Format’).

output: technology library file (.lib)

syntax: libgen <library source> <library file>

4. Experimental Results

Table 1 shows comparison of the hierarchical ATPG DECIDER [2] with twoother state-of-the-art test generation tools. These are GATEST [5] and HITEC [6],respectively. GATEST is a genetic algorithm based test generator. HITEC is adeterministic gate-level ATPG. Both of the tools have been developed at theUniversity of Illinois at Urbana-Champaign. The experiments were run on a 300MHz SUN UltraSPARC 10 workstation with 128 MB RAM under SOLARIS 2.6operating system. Actual stuck-at fault coverages of the test patterns generated byall the three tools were measured by the fault simulator from TURBO TESTERtools [7].

As it can be seen from Table 2, HITEC offers the poorest performance, both, interms of fault coverage and test generation time on all the three example circuits.Fault coverages achieved by GATEST and DECIDER are almost equal. GATESTreaches 1.2 % higher fault coverage for the gcd circuit and only 0.2 % highercoverage for diffeq. DECIDER in turn has a 2.1 % advantage in the case ofmult8x8 example. However, the test generation times of the two tools differgreatly. DECIDER spends 26 - 615 times less CPU time for test patterngeneration process than GATEST.

Table 1. Test generation results.

DECIDER [2] GATEST [5] HITEC [6]

Faultcover,%

Time, s Faultcover,

%

Time, s Faultcover,

%

Time, s

gcd 91.0 3.4 92.2 89.8 89.3 195.6

mult8x8 79.4 13.6 77.3 1585 63.5 1793

diffeq 95.8 15.8 96.0 9,720 95.1 N. A.

References1. J.Raik, R.Ubar, “Sequential Circuit Test Generation Using Decision Diagram

Models”, Proc. of DATE Conf., 1999.

2. R. Ubar, “Test Synthesis with Alternative Graphs”, IEEE Design & Test of Comp.,Spring 1996.

3. R. Ubar, “Test Generation for Digital Circuits Using Alternative Graphs”, Proc. ofTallinn Technical University, Estonia, No. 409, pp. 75-81 (in Russian), 1976.

4. S.B.Akers, “Binary Decision Diagrams”, IEEE Trans. Computers, Vol. 27, pp.509-516, June 1978.

5. T. M. Niermann, J. H. Patel, “HITEC: A Test Generation Package for Sequential Circuits”,Proc. European Conf. Design Automation, pp. 214-218, 1991.

6. E. M. Rudnick, J. H. Patel, G. S. Greenstein, T. M. Niermann, “Sequential Circuit TestGeneration in a Genetic Algorithm framework”, Proc. Design Automation Conf., pp. 698-704, 1994.

7. G.Jervan et al., “Turbo Tester: A CAD System for Teaching Digital Test”,Microelectronics Education, Kluwer Academic Publishers, Dordrecht/Boston/London, pp.287-290, 1998.

AppendixesAppendix A: SSBDD Model FormatSSBDD format is a line-based format. The Maximum length of a lineis 255 characters.Lines starting with ’;’ character are considered to be comments.

’STAT# x Nods, x Vars, x Grps, x Inps, x Outs ’Reflects the number of nodes, variables, graphs, primary inputs(PI) and primary outputs (PO),respectively.

’MODE#’ Mode- Where ’Mode’ can be one of the following:

STRUCTURAL - Structural alternative graph (SAG) model FUNCTIONAL - Functional alternative graph (FAG) model

The graph model is described as follows:

{Lines of variables}{<Line of a variable><Line of a graph>{Lines of nodes}}

Line of a variable in AG model:

’VAR# x:’ - Where x is variable index.

’(XXXXXXXX)’ - Flags. When a flag is not set, an underscore’_’will be placed to its position. Atpresent, six flags are implemented:

’i’ variable is an input variable ’o’ variable is an output variable ’c’ variable is a clock input ’0’ variable is a constant 0 input ’1’ variable is a constant 1 input ’D’ one clock cycle delay at the variable

’"’ string ’"’ - Variable name

Line of a graph:’GRP# x:’ - The index of a graph in graph table.

’BEG = x, LEN = x -----’ - The initial node index and the numberof nodes in the graph,respectively.

Line of a node:

’ x x:’ - Index and relative index of the node

’(XXXX)’ - Flags of the node.

’I’ - Denotes that the node is inverted

’D’ - Denotes that the node carries the previous state of thevariable.

’( x x)’ - Relative indexes of the nodes down and right fromcurrent node, respectively.

’V = x’ - Index of the weight variable of the node.

’"’ string ’"’ - Node name.

Appendix B: General DD Model FormatDD model format is case sensitive. It is a line-based format where maximum linelength can be 256 characters. In the following the BNF syntax of DD modelformat is presented. The meta-syntax used obeys the following rules:

I. Syntactic categories (nonterminals) are printed in italics; literal words,characters and constants are enclosed to ‘quotes’.

II. If a construct is enclosed to [square brackets], it is optional.

III. If a construct is enclosed to {curly brackets}, it may be repeated zero ormore times.

IV. A choice is indicated with a vertical bar |.

V. If a construct is enclosed in <chevrons>, it can occur at most once.

dd_model :=

statistics

mode

[control_signals]

dd_description

statistics :=

‘STAT#’ natural ‘Nods,’ natural ‘Vars,’ natural ‘Grps,’ natural ‘Inps,’ natural‘Outs,’ natural ‘Cons’ [‘,’ natural ’Funs’] [‘,’ natural ’Mems’] [‘,’ natural‘C_outs’]

The natural values reflect the number of nodes, variables, graphs, inputs, outputs,constants, functions, memory arrays and control part outputs, respectively. Thenumber of functions and memory arrays are meaningful in the high-leveldescriptions. The number of control part outputs is used with the RTLdescriptions divided into a control part and a datapath only.

control_signals :=

‘COUT#’ natural {‘,’ natural}

Shows the variable indexes of control signal variables. Used in RTL descriptionspartitioned to datapath and control parts.

mode :=

‘MODE#’ ‘STRUCTURAL’ | ‘RTL’ | ‘BEHAVIORAL’

Indicates whether a structural gate-level model, a RTL model, or a behavioralmodel is being described.

dd_description :=

[{input_definition}]

[{memory_definition}]

[{constant_definition}]

[{function_definition}]

[{control_definition}]

{graph_variable_definition}

The definitions are ranged according to the order shown above. There are nomemory definitions or function definitions in SSBDD models. control_definitionsare used only in the RTL descriptions partitioned into control and datapath parts.

input_definition :=

‘VAR#’ var_index ‘:’ ‘(‘ variable_flags ’)’ var_name var_range

Defines a primary input of the model.

memory_definition :=

‘VAR#’ var_index ‘:’ ‘(‘variable_flags’)’ var_name var_range [row_range]column_range

memory_row

{memory_row}

Defines a memory array. The optional row_range is used with two-dimensionalarrays, and it determines the range of row addresses used in memory. In one-dimensional arrays, row_range is omitted. In similar way, column_rangedetermines the range of column addresses used in the memory variable.

memory_row :=

‘{‘ integer {‘,’ integer} ‘}’

Defines the contents of a memory variable. The number of integers inmemory_row is determined by column_range.

row_range := mem_range

Row_range is used with two-dimensional arrays, and it determines the range ofrow addresses used in memory. In one-dimensional arrays, row_range is omitted.

column_range := mem_range

Determines the range of column addresses used in the memory variable.

mem_range := ‘[‘ integer ‘-’ integer ‘]’

In mem_range the first integer must be less than the second one.

constant_definition :=

‘VAR#’ var_index ‘:’ ‘(‘variable_flags’)’ var_name var_range ‘VAL’ ‘=’integer

Defines a constant. The integer value shows the value of the constant.

function_definition :=

‘VAR#’ var_index ‘:’ ‘(‘variable_flags’)’ var_name var_range

‘FUN#’ function_type arguments_definition

Defines an operation or function.

function_type := identifier

Shows the type of the operation.

arguments_definition :=

‘(‘ [argument] {‘,’ argument} ’)’

Defines the arguments (if any) of an operation.

argument :=

‘A’argument_index ‘<=’ argument_variable range

The range shows the bit-slice of the variable argument_variable that is used as afunction argument.

argument_index := natural

Shows the index of the function argument.

argument_variable := natural

Shows the index of the variable used as the function argument.

control_definition :=

‘VAR#’ var_index ‘:’ ‘(‘ variable_flags ’)’ var_name var_range

Defines a control signal. Used to define control part output signals of the RTLdesigns partitioned into datapath and control parts.

graph_variable_definition :=

‘VAR#’ var_index ‘:’ ‘(‘variable_flags’)’ var_name var_range

graph_definition

Defines a variable for which a graph corresponds.

graph_definition :=

‘GRP#’ graph_index ‘:’ ‘BEG’ ‘=’ natural ‘,’ ‘LEN’ ‘=’ natural ‘-----’

node_definition | parallel_node_definition

{node_definition | parallel_node_definition}

Defines a graph in the DD model. The ‘BEG=’ construct shows the absolute indexof the first node in the graph. The ‘LEN=’ construct in turn shows the number ofnodes in the graph.

node_definition :=

nod_abs_index nod_index ‘: (‘nod_flags’) (’ successors ‘) V =’ nod_varnod_name nod_range

Defines an DD node. nod_abs_index and nod_index represent the absolute (insidethe model) and relative (inside the graph) indexes of the node. Constructsuccessors shows the successor nodes of current node which are chosen withdifferent node values. Index of the variable labeling the node is determined withnod_var.

parallel_node_definition :=

nod_abs_index nod_index ‘: (v___)’ ‘(‘ ‘0’ ‘0’ ‘)’ ‘VEC =’ nod_var_vector

Defines a terminal node of the FSM graph of RTL description. nod_abs_indexand nod_index represent the absolute (inside the model) and relative (inside thegraph) indexes of the node, respectively. Indexes of the variables labeling thenode are determined with nod_var_vector.

nod_var_vector :=

‘ ”’ state_value {signal_value} ’ ”’

state_value shows the value of the next state. The signal_value constructs showthe values of the control signals defined in the control_signals construct.

state_value := natural

Shows the value of the next state.

signal_value := ‘0’ | ‘1’ | ‘X’

The signal_value constructs show the values of the control signals defined in thecontrol_signals construct.

nod_var := natural[ [ ‘[‘ ‘V’ ‘=’ row_index ’]’ ] ‘[‘ ‘V’ ‘=’ column_index ’]’ ]

Shows the index of the variable labeling the node. Optional constructs row_indexand column_index are used with memory variables labeling the node. These

constructs determine the indexes of the variables used for addressing rows andcolumns, respectively.

nod_name := string

Shows the name of the node.

nod_range := range

nod_range determines the bit-slice of the variable that labels the node. DD modelformat allows slices of variables to be used for labeling a node.

row_index := natural

Determine the indexes of the variables used for addressing rows of the memoryvariable.

column_index := natural

Determines the index of the variable used for addressing columns of the memoryvariable.

nod_abs_index := natural

Shows the absolute (inside the model) index of the node.

nod_index := natural

Shows the relative (inside the graph) index of the node inside the graph.

graph_index := natural

Shows the index of the graph.

variable_flags :=

< ‘i’ | ‘m’ | ‘c’ | ‘f’ | ‘o’ | ‘n’ | ’_’ | ‘F’ > {<‘d’> | ‘_’}

The variable flags have the following interpretation:

‘i’ - input variable

‘m’ - memory variable (RTL, behavioral)

‘c’ - constant variable

‘f’ - function variable (RTL, behavioral)

‘o’ - output variable

‘d’ - clock cycle delay, e.g. in registers, flipflops. (Gate-level, RTL)

The following flags are used with RTL descriptions only:

‘n’ - control part output signal

‘F’ - FSM graph variable

‘r’ - reset variable

‘s’ - state variable

nod_flags :=

< ‘i’ | ’_’ > { ‘n’ | ‘v’ | ‘_’}

The node flags have the following interpretation:

‘i’ - inverted node (in gate-level descriptions only)

‘n’ - non-terminal node (RTL, behavioral)

‘v’ - control part terminal node (RTL)

successors :=

nonterminal_successors | terminal_successor | boolean_successors

Construct successors shows the successor nodes of current node which are chosenwith different node values.

nonterminal_successors :=

node_values ‘=>’ successor_index {node_values ‘=>’ successor_index }

This construct shows the indexes of successor nodes which will be selected withcorresponding node values. (Used with RTL and behavioral models only).

terminal_successors := ‘0’ ‘0’

Terminal nodes are nodes which have no successor nodes.

boolean_successors:=

natural natural

This type of construct can be used with Boolean DDs only. The first naturalnumber indicates the relative index of the successor node when the value ofcurrent node is ‘0’, and the second number shows the relative index of thesuccessor node when current node is ‘1’, respectively. If the index of thesuccessor node is ‘0’, it shows that there is no successor nodes to current nodewith corresponding value.

node_values := natural { ‘,’ | ‘-’ natural}

Determines the set of node values that activate the corresponding branch. Thecomma ‘,’ character is used for separating the indexes; the minus sign ‘-‘ is usedfor index ranges, e.g. ‘3-5’, which can be alternatively written as ‘3,4,5’.

successor_index :=

natural | ‘X’

If successor_index is a natural number, it shows the index of the successor node.Otherwise, if successor_index is ‘X’, it means that the successor is undetermined.

var_index := natural

Shows the index of the variable.

var_name := string

Shows the name of the variable.

var_range := range

Shows the bitwidth of the variable.

range := [ ‘<’ natural ‘:’ natural ‘>’ ]

Range is a construct for describing bit-vectors. The first natural shows the indexof the most significant bit and the latter is for the least significant bit, respectively.If range is omitted, it will default to ‘<0:0>’.

string :=

‘ ” ’ {character} ‘ ” ’

Character can be any character, except newline and double quote ‘”’.

integer :=

[‘-’]natural

Any integer number.

natural

Natural can be any non-negative number.

identifier :=

alphabetic_character{alphabetic_character | digit | ‘_’}

alphabetic_character := ‘A’| …| ’Z’ | ‘a’ | …| ‘z’

digit := ‘0’ | ‘1’ | …| ‘9’

Appendix C: Library Source FormatThe library source format is used to generate custom technologylibraries for the EDIF interface. The syntax of the source is as follows.

GATE <cellName> <BooleanExpression> ;

, where cellName is the name of library cell

and BooleanExpression is:

<outputPin> = <BooleanFunction>

, where BooleanFunction is Boolean function of input pins.

Operators used in Boolean functions in order of priority:

() brackets (for priority),

! inversion,

* conjunction,

+ disjunction.

If BooleanFunction is CONST0 or CONST1, the library cell willcorrespond to logical zero or logical one signal.

Example

The following is an example of a source description for a library cellmy_nand2. It describes a two input nand gate with output pin y andinput pins a and b:

GATE my_nand2 y=!(a*b);

Appendix D: Technology Library FormatThe technology library is required by the EDIF interface in order toget information about the functionality of current technology librarycells. This information is not implicitly described in the EDIF netlistitself. The syntax of the technology library is as follows.

“ cellName “ numberOfRows

{<Row>}

, where cellName is the name of library cell;

numberOfRows is the number of rows in the cell;

and row consists of:

lineNumber name type numberOfOutputs numberOfInputs

[listOfInputs]

, where lineNumber is the index of row in the library cell, name is thename of the gate in the cell and type can be one of the following:

inpt cell input

from fanout branch

and and gate

nand nand gate

or or gate

nor nor gate

not inverter

numberOfOutputs is the number of fanout branches of the gate

numberOfInputs is the number of gate inputs

listOfInputs contains an array of indexes separated by spaces toindicate the line numbers of pins connected to corresponding gateinputs.

Appendix E: Design example (RT-LevelVHDL)

-- The VHDL code generated by CAMAD:

LIBRARY MGC_PORTABLE;USE MGC_PORTABLE.QSIM_LOGIC.ALL;

USE Work.ETPN_modelling.ALL;

ENTITY /../MAGISTER/designs/mult8x8 IS PORT ( P_N1, P_N4, P_N5 : IN BIT; -- input pads P_N6 : OUT UNSIGNED16; -- output pads Reset : IN BIT := ’0’; -- reset signal Clock : IN BIT := ’0’ -- clock signal );END;

ARCHITECTURE Structure OF /../MAGISTER/designs/mult8x8 IS -- signals for component connection points SIGNAL N_A5 : BIT; SIGNAL N_A6 : UNSIGNED8; SIGNAL N_A7 : BIT; SIGNAL N_A8 : UNSIGNED8; SIGNAL N_A9 : UNSIGNED8; SIGNAL N_A10 : UNSIGNED8; SIGNAL N_A11 : UNSIGNED8; SIGNAL N_A12 : BIT; SIGNAL N_A13 : UNSIGNED32; SIGNAL N_A14 : UNSIGNED3; SIGNAL N_A15 : BIT; SIGNAL N_A17 : UNSIGNED32; SIGNAL N_A18 : UNSIGNED2; SIGNAL N_A19 : UNSIGNED32; SIGNAL N_A20 : BIT; SIGNAL N_A21 : BIT; SIGNAL N_A23 : UNSIGNED32; SIGNAL N_A24 : UNSIGNED32; SIGNAL N_A25 : UNSIGNED32; SIGNAL N_A27 : UNSIGNED2; SIGNAL N_A28 : UNSIGNED32; SIGNAL N_A30 : UNSIGNED2; SIGNAL N_A31 : UNSIGNED32; SIGNAL N_A33 : UNSIGNED32; SIGNAL N_A34 : UNSIGNED32; SIGNAL N_A36 : UNSIGNED2; SIGNAL N_A37 : UNSIGNED32; SIGNAL N_A38 : BIT; SIGNAL N_A39 : BIT; SIGNAL N_A43 : UNSIGNED32; SIGNAL N_A45 : BIT; SIGNAL N_A46 : BIT; SIGNAL N_A47 : BIT; SIGNAL N_A49 : UNSIGNED32; SIGNAL N_A50 : UNSIGNED32; SIGNAL N_A51 : UNSIGNED32; SIGNAL Unconnected : UNSIGNED32;

-- control signals from the control Petri net SIGNAL P0, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12, P13, P14, P15, P16, P17, P18, P19, P20, P21, P3_P9_P12_P16, P4_P11, P6_P13 : BIT;

-- condition signals from the data path SIGNAL C3, C4, C5, C6 : BIT;

-- data path component types COMPONENT Pad1 PORT ( Ip1 : IN BIT; -- input Op1 : OUT BIT -- output ); END COMPONENT;

COMPONENT Pad8 PORT ( Ip1 : IN UNSIGNED8; -- input Op1 : OUT UNSIGNED8 -- output ); END COMPONENT;

COMPONENT Pad16 PORT ( Ip1 : IN UNSIGNED16; -- input Op1 : OUT UNSIGNED16 -- output ); END COMPONENT;

COMPONENT Reg32 PORT ( Ip1 : IN UNSIGNED32; -- input Ic1 : IN BIT; -- load control clock : IN BIT; -- load control Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

COMPONENT Add8 PORT ( Ip1, Ip2 : IN UNSIGNED8; -- input Op1 : OUT UNSIGNED8 -- output ); END COMPONENT;

COMPONENT Mlt8 PORT ( Ip1, Ip2 : IN UNSIGNED8; -- input Op1 : OUT UNSIGNED8 -- output ); END COMPONENT;

COMPONENT LeE32 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Op1 : OUT BIT -- output ); END COMPONENT;

COMPONENT Eql32 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Op1 : OUT BIT -- output ); END COMPONENT;

COMPONENT Mod32 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

COMPONENT Add32 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

COMPONENT Div32 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

COMPONENT Sub32 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

COMPONENT Eql1 PORT ( Ip1, Ip2 : IN BIT; -- input Op1 : OUT BIT -- output ); END COMPONENT;

COMPONENT Mul32_4 PORT ( Ip1, Ip2, Ip3, Ip4 : IN UNSIGNED32; -- input Ic1, Ic2, Ic3, Ic4 : IN BIT; -- multiplex selection Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

COMPONENT Mul32_2 PORT ( Ip1, Ip2 : IN UNSIGNED32; -- input Ic1, Ic2 : IN BIT; -- multiplex selection Op1 : OUT UNSIGNED32 -- output ); END COMPONENT;

-- data path component configuration

FOR N1, N4, N5, N6 : Pad1 USE ENTITY Work.Pad1(behavior); FOR N1, N4, N5, N6 : Pad8 USE ENTITY Work.Pad8(behavior); FOR N1, N4, N5, N6 : Pad16 USE ENTITY Work.Pad16(behavior); FOR N7, N8, N9, N19 : Reg32 USE ENTITY Work.Reg32(behavior); FOR N15 : Add8 USE ENTITY Work.Add8(behavior); FOR N17 : Mlt8 USE ENTITY Work.Mlt8(behavior); FOR N21 : LeE32 USE ENTITY Work.LeE32(behavior); FOR N25, N38 : Eql32 USE ENTITY Work.Eql32(behavior); FOR N26, N39 : Mod32 USE ENTITY Work.Mod32(behavior); FOR N31, N36 : Add32 USE ENTITY Work.Add32(behavior); FOR N32, N34 : Div32 USE ENTITY Work.Div32(behavior); FOR N44 : Sub32 USE ENTITY Work.Sub32(behavior); FOR N45 : Eql1 USE ENTITY Work.Eql1(behavior); FOR N49 : Mul32_4 USE ENTITY Work.Mul32_4(behavior); FOR N50, N51 : Mul32_2 USE ENTITY Work.Mul32_2(behavior);

-- FSM state declaration TYPE State_type IS (S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18, S19, S20, S21); SIGNAL present_state : State_type; SIGNAL next_state : State_type;

BEGIN -- component instantiation N1 : Pad1 PORT MAP (P_N1, N_A45); N4 : Pad8 PORT MAP (P_N4, N_A6); N5 : Pad8 PORT MAP (P_N5, N_A9); N6 : Pad16 PORT MAP (N_A23, P_N6); N7 : Reg32 PORT MAP (N_A49, P3_P9_P12_P16, clock, N_A23); N8 : Reg32 PORT MAP (N_A50, P4_P11, clock, N_A17); N9 : Reg32 PORT MAP (N_A11, P5, clock, N_A24); N15 : Add8 PORT MAP (N_A6, N_A7, N_A8); N17 : Mlt8 PORT MAP (N_A9, N_A10, N_A11); N19 : Reg32 PORT MAP (N_A51, P6_P13, clock, N_A13); N21 : LeE32 PORT MAP (N_A13, N_A14, C3); N25 : Eql32 PORT MAP (N_A19, N_A20, C4); N26 : Mod32 PORT MAP (N_A17, N_A18, N_A19); N31 : Add32 PORT MAP (N_A23, N_A24, N_A25); N32 : Div32 PORT MAP (N_A17, N_A27, N_A28); N34 : Div32 PORT MAP (N_A23, N_A30, N_A31); N36 : Add32 PORT MAP (N_A13, N_A33, N_A34); N38 : Eql32 PORT MAP (N_A37, N_A38, C5); N39 : Mod32 PORT MAP (N_A17, N_A36, N_A37); N44 : Sub32 PORT MAP (N_A23, N_A24, N_A43); N45 : Eql1 PORT MAP (N_A45, N_A46, C6); N49 : Mul32_4 PORT MAP (N_A5, N_A25, N_A31, N_A43, P3, P9, P12, P16, N_A49); N50 : Mul32_2 PORT MAP (N_A8, N_A28, P4, P11, N_A50); N51 : Mul32_2 PORT MAP (N_A12, N_A34, P6, P13, N_A51);

-- The FSM controller state_register:PROCESS( reset, clock ) BEGIN IF ( reset = ’0’ ) THEN present_state <= S1; ELSIF ( clock = ’1’ AND clock’LAST_VALUE = ’0’ AND clock’EVENT ) THEN present_state <= next_state; END IF; END PROCESS state_register;

output_decode_logic:PROCESS( clock, present_state ) BEGIN P0 <= ’0’; P1 <= ’0’; P2 <= ’0’; P3 <= ’0’; P4 <= ’0’; P5 <= ’0’; P6 <= ’0’; P7 <= ’0’; P8 <= ’0’; P9 <= ’0’; P10 <= ’0’; P11 <= ’0’; P12 <= ’0’; P13 <= ’0’; P14 <= ’0’; P15 <= ’0’; P16 <= ’0’; P17 <= ’0’; P18 <= ’0’; P19 <= ’0’; P20 <= ’0’;

P21 <= ’0’; CASE present_state IS WHEN S1 => P0 <= ’1’; WHEN S2 => P2 <= ’1’; WHEN S3 => P3 <= ’1’; WHEN S4 => P4 <= ’1’; WHEN S5 => P5 <= ’1’; WHEN S6 => P6 <= ’1’; WHEN S7 => P7 <= ’1’; WHEN S8 => P8 <= ’1’; WHEN S9 => P14 <= ’1’; WHEN S10 => P9 <= ’1’; WHEN S11 => P10 <= ’1’; WHEN S12 => P15 <= ’1’; WHEN S13 => P11 <= ’1’; WHEN S14 => P16 <= ’1’; WHEN S15 => P17 <= ’1’; WHEN S16 => P12 <= ’1’; WHEN S17 => P18 <= ’1’; WHEN S18 => P13 <= ’1’; WHEN S19 => P19 <= ’1’; WHEN S20 => P20 <= ’1’; WHEN S21 => P21 <= ’1’; END CASE; END PROCESS output_decode_logic;

state_decode_logic : PROCESS( C3, C4, C5, C6, present_state ) BEGIN CASE present_state IS WHEN S1 => next_state <= S2; WHEN S2 => next_state <= S3; WHEN S3 => next_state <= S4; WHEN S4 => next_state <= S5; WHEN S5 => next_state <= S6; WHEN S6 => next_state <= S7; WHEN S7 => IF C3 = ’1’ THEN next_state <= S8; ELSE next_state <= S9; END IF; WHEN S8 => IF C4 = ’1’ THEN next_state <= S10; ELSE next_state <= S11; END IF; WHEN S9 => next_state <= S12; WHEN S10 => next_state <= S11; WHEN S11 => next_state <= S13; WHEN S12 => IF C5 = ’1’ THEN

next_state <= S14; ELSE next_state <= S15; END IF; WHEN S13 => next_state <= S16; WHEN S14 => next_state <= S15; WHEN S15 => next_state <= S17; WHEN S16 => next_state <= S18; WHEN S17 => next_state <= S19; WHEN S18 => next_state <= S7; WHEN S19 => next_state <= S20; WHEN S20 => next_state <= S21; WHEN S21 => IF C6 = ’1’ THEN next_state <= S2; ELSE next_state <= S19; END IF; WHEN OTHERS => next_state <= S1; END CASE; END PROCESS state_decode_logic;

-- Other control signals P3_P9_P12_P16 <= P3 OR P9 OR P12 OR P16; P4_P11 <= P4 OR P11; P6_P13 <= P6 OR P13;

-- Constants N_A5 <= 0; N_A7 <= 0; N_A10 <= 128; N_A12 <= 0; N_A14 <= 6; N_A18 <= 2; N_A20 <= 1; N_A27 <= 2; N_A30 <= 2; N_A33 <= 1; N_A36 <= 2; N_A38 <= 1; N_A46 <= 1;END;

Documents

Fault Simulator and ATPG for Complex Digital Circuits