Review of software tools tosupport computer-aided testing ofdigital circuitsby Ben BennettsCenRad (Fareham)

This paper reviews the requirements and status of software to supportthe generation of test vectors for a digital circuit and the subsequentconversion into a working test program on ATE. The paper focuseson: language systems to describe circuit topology, circuit behaviourand waveforms; test pattern generation techniques; evaluation byfault simulation; postprocessing to ATE; and engineering workstationuser interfaces. The conclusion comments on the need for anintegrated design and test environment, based on the same tool setand data structure.

Introduction

The development of computer aids tosupport the production of test pro-grams for digital integrated circuits andprinted circuit board assemblies is acontinuous process. This paper sum-marises the state of the art in terms ofthe software tools that are currentlyavailable or under development. Acompanion paper, by Birger Schneider(Ref. 1), considers the developmentswithin the automatic test equipment(ATE) hardware.

Fig. 1 shows the overall environmentwithin which the tools are used. Thetwo major input requirements aredefined in terms of languages todescribe circuit topology and behaviourand stimulus/response waveforms.

These languages allow entry into thecore simulation and test generationsoftware which cause test vectors to begenerated. The test quality of these vec-tors is assessed by a fault simulatorwhich produces a measure of effective-ness in terms of fault coverage. If thecoverage is inadequate against pre-determined objectives, the user caneither return to the test generation sys-tem and attempt to generate more tests,or modify the objectives accordingly.

At some point in the process, the userwill exit with some tests. These will be inthe format and data structures of thesimulation system. The final stage is toconvert to the appropriate formats ofthe target tester. This conversion is car-ried out by a postprocessing package.

This paper looks at each of thesemajor software elements in turn. Thestyle of the paper is tutorial, and each

element will be discussed in terms of:

• the requirement, as seen by a testprogrammer• the principle, as seen by the tooldeveloper• the characteristics of present tools,as seen by a user.

Language system tools

Modelling circuit behaviour (Fig. 2)The requirement is to allow the test

programmer to describe the logical and

timing behaviour of the circuit or parti-tioned sub-circuits as a base model for asoftware simulation system.

The principle of operation of the soft-ware is to provide a high-level circuitdescription programming languagecapable of defining and combiningdetailed and accurate statements thatreflect the logical and timing behaviourof the circuit.

The characteristics of current toolsare as follows:

• a wide range of circuit primitives (atswitch, gate and functional level)• usually hierarchical, allowing macrodefinition and calling• accurate timing specification is pos-sible, including min-typ-max propa-gation delay, set-up and hold limits• multi-valued representation of alogic level, for example logic-0, logic-1,high-impedance, weak-0, weak-1,unknown• high-level programming constructs

fault - coverobjectives test vectors

fault grading

enhance / modify objectives: s . t i ,

postprocessor

t a r g e t A T E

Fig. 1 The tools environment

Computer-Aided Engineering Journal August 1986 143

. . - * :« . - , -s - • T V ^# *

Fig. 2 Circuit topology and behaviour language

such as event definition, conditionalbranching, loop constructs, registertransfer, Boolean and arithmetic datamanipulation, parametrisation• constructsfordefiningcircuit nodes(often called nets) in terms of deviceterminals, interconnect wires, unidirec-tional or bidirectional nature• constructs for defining node-to-node interconnects.

Specification of a waveform (Fig. 3)The requirement is to allow the test

programmer to specify a set of input pinstimuli with, optionally, the corre-sponding responses expected on theoutput pins if the circuit is operatingcorrectly.

The principle is to provide a high-level language with constructs to sup-port both low-level and high-levelwaveform definition. Low level means'change the value on this pin from 1 to0'; high level means 'interpret thisalgorithm as a sequence of valuechanges on this set of pins'.

The characteristics are as follows:

• in a general-purpose test generationsystem, the language is tester indepen-dent, but sufficiently powerful to allowconversion into a range of ATE types• in a test generation system targetedon to a single ATE family, the language isitself the ATE language and can

Fig. 3 Stimulus/response waveform language

obviously reflect very accurately thehardware characteristics of the ATE• constructs to allow accurate repre-sentation of both circuit and tester tim-ing cycles and formats• assignment and equivalence state-ments (an assignment statement says'set this node to this level'; an equiv-alence statement says 'expect this levelon this node')• higher-level constructs to allowlooping, shifting, manipulation ofBoolean data, arithmetic operations• parametrised processes and pro-cedures — a procedure is called andexecuted as part of the main flow of thetest program; a process runs con-currently with the main flow of the testprogram, and would be used, forexample, to define a repetitive back-ground event such as a read/writerefresh cycle• user-defined or system-definedstrobe points to define precisely whenoutput response values can be sampledand tested by the tester.

Test pattern generation tools

Algorithmic pattern generation(Fig. 4)

The user requirement is for analgorithm to generate test patternsautomatically for all known logic circuit

.algorijihmictestiginl^tor.,

4es.t! p.atteftiis5*

Fig. 4 Test pattern generation/evaluation

144

configurations, and to a given fault-cover specification (discussed later),given only a specification of how thecircuit behaves and is connected asdefined by the circuit descriptionlanguage.

Most 'successful' algorithms in thisarea are based on the principle of pathenumeration to sensitise the value of atleast one ATE contact point (device pinlead, board test point, in-circuit accesspoint, edge-connector finger) to thepresence or absence of a specified faultcondition on a specified internal (non-accessible) logic node. In essence, theprinciple is shown in Fig. 5 and outlinedbelow:

• Step 1: Pick any node, or set ofnodes, in the circuit.• Step 2: Impose a logic value (or setof values) corresponding to a known orassumed failure mechanism.• Step 3: Determine a path throughthe circuit to an ATE-observable node insuch a way that the logic value observedby the ATE on the output node is dif-ferent according to the presence orabsence of the predefined fault. Such apath, when created, is called a sensitivepath.• Step 4: Determine a set of consist-ent values on the inputs to the circuit tocause such a path to be created. Thesevalues define the test input values.• Step 5: Repeat steps 1-4 for allnodes and all faults, as defined by thecircuit topology and target fault list,respectively. .

The characteristics (Fig. 6) of currentalgorithmic pattern generation toolsare:

• Algorithms based on this principlefall into the class of problems whosesolutionsare NP-complete; i.e. the timeneeded by the algorithms to produce ananswer is of exponential order.• This means that, in practice, the

Computer-Aided Engineering Journal August 1986

, ^j,uj6lef.<-c / / . ^ <*" laiigejy insoluble; >,

.vui5ttelpf

Fig. 5 Algorithmic pattern generation — principle of operation Fig. 6 Algorithmic test generation characteristics

algorithms are limited to relatively smallcircuits of combinational or simple-structured sequential form (no inter-woven feedback paths or complexinteraction feedforward paths).• The algorithms are thereforecharacterised by long run times,incomplete solutions and unhelpfultermination.• Certain versions, however (forexample PODEM, critical path), areknown to be successful for.well disci-plined designs such as pure combi-national or the combinational sectionsof scan designed circuits.

Pseudo-random and statisticalpattern generation (Fig. 7)

The requirement is as foralgorithmicpattern generation above.

As an alternative to the deterministicalgorithmic approach, a large numberof input value changes are generated bya pseudo-random generator. Normallogic simulation is used to determinethe expected fault-free outputresponses. Statistical analysis is used todetermine the probability that all thefaults in a target fault list would bedetected by the sequence.

The characteristics are as follows:

• These tools provide a low-costmethod for generating test patterns,but the true fault cover, as determinedby a fault simulator (discussed later),cannot be defined because of the exor-bitant cost of carrying out the faultsimulation exercise.• Statistical fault-cover analysis canindicate high (better than 90%) faultcoverage, but engineering intuitiontends to distrust these figures.• Pseudo-random sequences tend toproduce patterns which detect faults forwhich the deterministic approachesalso work quite well. The hard-to-detectfaults remain hard to detect for both thedeterministic and pseudo-randomapproaches.• Thenumberof patterns generated isusually at least one or two orders ofmagnitude greater than the numbergenerated by an algorithmic approach.This feature increases test applicationrun times on an ATE and thus reducesthroughput.

Knowledge-based patterngeneration (Fig. 8)

The requirement is again as foralgorithmic pattern generation.

A test programmer creating a pro-

gram manually makes use of manypieces of knowledge about how the cir-cuit is designed to operate and how it isconstrained. This knowledge is intrinsicto the design and is extracted by theprogrammer according to his experi-ence, both in design and in test. Theprinciple of knowledge-based patterngeneration is to identify and captureuseful pieces of knowledge about thecircuit which can subsequently be usedto guide a pattern generation process toreach a solution quickly and accurately.The pieces of knowledge most helpfulinclude:

• how to establish a given logic levelon a given internal node (this is termedcontrollability knowledge)• how to sensitise a path from a giveninternal node to an observable output(this is termed observability)• constraints on the behaviour of alogic sub-circuit caused either bydeliberate partial usage or by con-straints imposed by logically adjacentsub-circuits• knowledge about the structure(topology) of the circuit, particularlyfeedback paths.

The characteristics of knowledge-based

.; r ; j>fr v-;'.V--^r%-; „, v \

>* •

• i . - . -

1 \ H J . * ^ ^ V1.As!JP.','~V' '• • *v" ' 'test pafte'ms

Fig. 7 Test pattern generation/evaluation — other approaches

Computer-Aided Engineering Journal August 1986

Fig. 8 Test pattern generation/evaluation — knowledge based

145

Nrst ' 1 ' •* .w .ay 4 e 'onro igGad in igp , »• ' •

'"t"^ "J,\ v*j" > • ' , • '

Fig. 9 Fault simulation

-(V

L

> /

I

—

1010/1/S1110/0/S ~ "

+fault dictionary — »

+nodal binary values —•»

V

O,-,w -'-W,

"Ay „. 8< ,A "

f»•

!• —

• some hand-crafting• source and sink formats are moving targets

ATE

a t

/̂c/f

Fig. 10 Postprocessing

pattern generation tools currently avail-able are as follows:

• Pattern generation systems basedon the capture and use of knowledgeitems are still in their infancy and there-fore largely untried in a commercialenvironment. Potentially, however,they offer the only route forward forwhat is known to be an extremely com-plex problem (test pattern generation).• They can be designed to be helpful

on failure and with very interactiveinterfaces to assist in creating andchecking knowledge data.• A knowledge database is created tohold the knowledge items. Stored-statedevices or groups of devices are identi-fied. Control and observe waveformsdefine waveform fragments to movedata through the stored-state devices.Signal constraint data is used to ensurethat the test generator does not gener-ate test data that violates circuitbehaviour. Parametrised waveform pro-

cedures constrain input waveforms toobey normal circuit timing constraintsand to conform to tester timing limits.

• The test patterns so generated areboth structured and meaningful andthus can be further edited manually.

Fault simulation tools

The requirement is to determine, bysimulation, the predicted fault cover ofa sequence of test inputs to a logicalcircuit, given the waveform and circuitdescriptions and a list of target faults(see Fig. 9).

The principle of operation of thesetools is to simulate the behaviour of thecircuit against a given input waveform:

• with assumed fault-free conditionsto obtain the good-circuit outputresponse, and

• with an assumed fault, or set offaults, which over-rides the computedgood value on a node, or set of nodes,and to determine whether the circuitoutput responses now differ from thereference good-circuit values.

If the two sets of outputs differ, then theinput waveform is deemed to be a testcondition for the assumed fault, or setof faults. The process then continueswith other faults taken from the fault listand with other input waveforms as com-puted by the test generation tools, orderived manually.

The target set of faults is usually basedon a set of fault models which reflect theknown failure mechanisms of the cir-cuit. Typically this set of fault modelsincludes single nodes stuck at logic-1,stuck at logic-0, stuck at high imped-ance, stuck open circuit, stuck short cir-cuit (node-to-node).

A set of test waveforms is usuallyjudged adequate if the final faultcoverage is in excess of 95% of the initialtarget fault list.

The characteristics of present faultsimulation tools are:

• There are various techniques fordesigning and building fault simulators(serial, parallel, concurrent, parallel-value list). They all perform essentiallythe same function but differ in the waythat they store, organise and propagatefault values.• Speed of execution is usually moreimportant than memory requirements.• Inadequate or inaccurate fault-effect models sometimes cause doubtas to the validity of an x% fault-covergrading on a set of test vectors. Thismethod of grading is the only practicaltechnique available, and so the industrylives with the inadequacy.• Long run times can be reduced byvarious techniques, such as fault sam-pling (with associated statistical analysis

146 Computer-Aided Engineering Journal August 1986

again), fault collapsing and hardwareaccelerators.• The need to retain timing accuracyas well as logical accuracy during thesimulation in the presence of faultsincreases run time.• Secondary analysis of the faultsdetected per test allows the con-struction of test/fault tables which formthe base of a fault dictionary. Such adictionary is used by many ATEs to assistin the process of fault location.

Postprocessing tools

The requirement is to translate ATE-independent output files from test gen-eration/fault simulation systems into aformat which is acceptable to a targetATE (Fig. 10). The files will include:

• circuit interconnect structure (thenetlist)• test input waveforms with expectedgood-circuit output values plus strobepositions• fault dictionary files• good-value binary data for thesequence of logic values on some or allinternal nodes (used by more sophisti-cated ATE diagnostic routines).

Regarding the principle of operation, inessence these translators are generallysyntax transformers, converting thesyntax of the test generation system intothe syntax of the target tester.

The characteristics are as follows:

• Because of the problem of trans-forming from a general-purpose allembracing syntax to a specific syntax,most translators of this sort are not fullyautomatic. The user needs to hand-craftsome of the statements either becausethere is no direct match or because thetester contains features over and abovethose of the general system.• Translators are the subject of con-stant change as either or both thesource and target formats change.

User interface tools

Most tools to support test generationnow run on stand-alone workstationproducts or workstation terminals net-worked to machines of greater comput-ing power. This means that userinterface tools are based on those avail-able on the workstation. These include:

• menu driven input

• multi-windows with text and sche-matic display• colour graphics• schematic capture with automaticconversion to textual netlist form• a waveform display, similar to a logicanalyser• hierarchy, through zoom facilities.

circuit designer

• faster• more complex• little design for test

CAT tools designer

KNOWLEDGE

Fig. 11 Closing the design-test gap

Conclusion

Software tools for computer-aideddesign of test programs are immenselysophisticated, but such is the pace ofchange in design itself that the tools arecontinuously under development. Per-haps one of the most exciting recentbreakthroughs has been the use of con-cepts taken from expert system practiceand applied, through knowledge engin-eering, to the seemingly intractableproblems of test pattern generation.

The capture and use of design know-ledge is seen by many to be absolutelyessential if the gap between the circuitdesigner's achievements and the

computer-aided test tools developer isto be kept small (Fig. 11). Designers areobviously producing circuits which arefaster, more complex and, in somecases, have little regard for design fortest.

Another breakthrough has been theconsiderable improvement to userinterfaces 'donated' by the vendors ofengineering workstations. Without adoubt, the industrial thrust to achieveintegrated design and test processeswill force yet more changes on the testrelated tools. True integration,although seen by toolmakers and usersalike to be a laudable objective, is prov-ing difficult to achieve. The thrust willcontinue.

Reference

1 SCHNEIDER, B.: 'ATE systems — current trends and integration into CAE environments',Computer-Aided Engineering Journal, 1986, 3, (4), pp. 148-I54

Bibliography

1 BENNETTS, R. C : 'Introduction to digital board testing' (Crane-Russak (New York)/Edward Arnold (London), 1985)

2 BENNETTS, R. G.: 'Design of testable logic circuits' (Addison-Wesley, 1984)3 MAUNDER, C , and BENNETTS, R. C : 'HITEST — using knowledge in test generation',

Computer-Aided Engineering Journal, 1985, 2, (3), pp. 75-83

This paper was presented as an invited tutorial at Eurocon, the European Conference onElectrotechnics, held in Paris, France, on 21st-23rd April 1986. A shorter form of the paperappears in the Conference Proceedings.Dr. R. C. Bennetts is with CenRad (Fareham), Waterside Gardens, Fareham, Hants. PO'ld HRR,England.

Computer-Aided Engineering Journal August 1986 147