Logic Design for Array-Based Circuits

by Donnamaie E. White

Copyright © 1996, 1998 Donnamaie E. White
Last Edit July 15, 1998

Chapter 2 Continued

Pre-Simulation Steps

Once an array or array series has been selected, the design can be captured and all checking performed with packaged or vendor software. For non-schematic designs, the steps leading to the netlist are performed per the system requirements. [Verilog and VHDL are the two leading circuit description techniques.] Once a netlist exists, the design steps are the same.

Perform schematic capture through netlist generation

Perform the schematic capture using the Dazix, Mentor, Valid or other EWS (Electronic WorkStation) system; Lasar 6, Verilog or other netlister equipped with schematic-generation software.

Perform the schematic capture following vendor schematic rules and conventions.

Perform the vendor-software steps through netlist generation

Each workstation had a different netlist format and a different procedure to generate it. Each workstation had its own simulator that uses the workstation-specific netlist as an input file. LASAR 6 (Vax/VMS) and Verilog each has a specific netlist format. Transfer of a design from the design workstation to a vendor must be done using a netlist the array vendor can recognize. (See Figure 2-2.)

An array vendor may be limited to accepting only those designs created on a workstation that matches the equipment that the vendor has in-house.

Most design input today is done without schematic capture. Cadence Composer can handle schematics. Design Compiler from Synopsys will display a schematic after synthesis (best used at the module level). Today;'s engineers use Verilog or VHDL netlist to input a circuit description. Design Compiler produces a Verilog netlist, an EDIF netlist and a Synopsys .db formatted file for design transfer.

Figure 2-2 Netlister Confusion

Another solution is the use of a dial-up design system based on a mainframe. The array vendor provides the account access for a fee and provides all required support and the designer provides an acceptable terminal. The problem is the access to a compatible terminal when a graphics terminal is required and the costs of the design in connect time.

To combat the problem of multiple formats without moving to a dial-up solution, netlist reformatters or translation programs have been written.

AMCC has a netlist formatter, AGIF, which is customized to each supported workstation and netlister. The AMCC Generic Interface Format file produced is called circuit.sdi and it is the means of communication between the customer and all AMCC software, including the MacroMatrix components: AMCCERC, AMCCANN, AMCCVRC, AMCCSIMFMT, AMCCSUBMIT and AMCCAD for placement.

Perform design rules checking

For systems and vendors without software support or with support that is less than complete, the design checks must be performed manually. EWS-based checking provided by the EWS vendor is minimal and should only be used as a first step in the validation process. Intelligent checkers are evolving. These may be interactive with a schematic capture or work on the standardized netlist.

The checker must be successfully completed before proceeding. Remove all errors if possible, and document those that remain. The vendor may require a waiver before submission if errors are not removed from the circuit.

AMCC customers must run AMCCERC and remove errors. The program output, AMCCERC.LST, provides reports on population, I/O types and mixes, utilization, package signal pin requirements, DC power, internal pin count, and SSO power-ground evaluation while listing naming violations, unconnected pins, pin connect violations, fan-out loading violations with derated loads, and technology (array, power-supply, and macro mismatch) errors. AMCCERC.LST must be included with the design submission package.

Generate extrinsic load time delays (Annotation)

The need for annotation software came from the change in the ratio between the delays caused by the interconnect between macros and the macro internal (intrinsic) delays. Once it was common for an interconnect net delay to exceed one half of the intrinsic delay, or even to exceed the intrinsic delay, it became necessary to produce a reasonable estimate of the interconnect delay.

Figure 2-3 Schematic And Netlist Paths Into AMCC

Front-Annotation is the term used for pre-placement-pre-route interconnect delay estimation. The estimate is based on the net size, number of fan-out loads, both physical and electrical, or the capacitive load on an output macro.

The Front-Annotation programs such as AMCCANN compute the fan-out loading delay, the wire-OR loading delay, and provide an estimate of the metal etch delay due to the size of the nets. The estimate is based on a statistical evaluation of previously built circuits and the average etch length used to connect same-sized nets. It is too large a number some of the time and too small of a number at other times. Front-Annotation is not a specification.

Where Intermediate-Annotation is available (a Manhattan-Distance algorithm based on a placement file), it should be used. It is more accurate in more case but it is still an estimate. Only after place and route can the actual metal etch delays be known. Annotation after place and route is called Back-Annotation.

Perform testability analysis on the circuit.

All testability measures have one common goal: to enhance controllability and observability of the circuit. It is a grade on the logic design itself. Controllability is a measure of the ease in setting a particular node to a logic level of zero or one, while observability determines the ease of propagating the node's state to one or more primary outputs.

After a netlist has been created and logic simulation has verified correct functional performance, testability can be verified by running testability analysis programs. This optional step is highly recommended if there is software available to perform the analysis. For a modular design, a manual review should be performed if there is no software support.

The purpose is to identify those parts of the circuit that are difficult or impossible to reach by way of primary inputs (controllability), and those parts of the circuit that may change state but that are difficult or impossible to observe at a primary output (observability). Steps should be taken to make hard to reach nodes controllable by adding test control signals and degating logic. Make hard to observe nodes observable by adding test points.

Make any adjustments or changes to the schematic as necessary to improve testability to acceptable limits. Changing the schematic will mean repeating the error-checking and annotation software steps.

Testability analysis should be done before simulation since the result will be to simplify the functional simulation vector set development.


Once the circuit has been checked for design rule violation, sizing, power, package fit, optimization, functionality and other non-simulation dependent checking, the simulations required by the array vendor may be performed. There are several types of simulations: functional (all etch is connected without SA0, SA1 faults); at-speed (the array-implemented design runs at the specified maximum operating frequency of the circuit); AC test (path propagation delay) and parametric (VIH, VIL). The array vendor may specify the simulations, formats required, and vector rules to be followed.

Modular simulations - Debug only

During logical debug of the original design it is better to simulate modular segments of the circuit, verifying basic logical operation and debugging the immediately obvious design errors. Once the circuit is considered to be a successful logical design, then perform the functional simulation that will form the basis of the test vectors submitted with the design. Multiple fragmented functional simulations cannot be submitted.

Functional simulation

The object of functional testing is to detect a single SA1 (stuck-at-1) or SA0 (stuck-at-0) fault in the circuit if one exists. This ideally requires sufficient vectors to "cover" all possible SA1 and SA0 fault locations. The percentage of coverage is the fault grade of the vector set. For a high fault-grade score (95% and up), other types of circuit failures are assumed to be "covered".

Functional test vectors are initially created from the functional simulation sampled results file. Functional simulations are run using Front-Annotation or Intermediate-Annotation with timing checks enabled. They are re-executed when Back-Annotation is available. It is the Back-Annotated simulation result file that goes to test.

The functional vector set for a circuit should detect any single fault occurring on a single path. In theory, triple faults, odd faults of 5, etc., per path are covered by the vectors detecting single faults provided the faults do not mask each other. Even-numbered sets of faults on a path (double faults, quad faults, etc.) are assumed to mask each other and not to be detectable. The probability of multiple faults on a path is significantly less than the probability of a single fault. (Multiple faults that signal a catastrophic failure are detected within the basic wafer screening.)

Figure 2-4a Simulations - Types And Forms


Figure 2-4b Circuit Simulation Requirements

Redundant circuit logic will cause some faults to be masked (prevent their detection) and should be avoided. Where redundancy is desired for other reasons, the designer should add test points to make masked faults visible.

One extreme approach used to develop functional vectors is to cycle all inputs and outputs through all combinations of 1-0 and 0-1 transitions as a first check after initialization. (Theoretically, this should cycle all internal nodes in a combinatorial circuit as well.) This 2n (where n = number of inputs) brute force approach is not necessary.

Minimum vector test sets and minimum vector test sequences will cover 100% of all observable faults. A fault cannot be detected by any test methodology if it is a masked fault. A masked fault cannot be seen at a primary output due to redundancy in the logic. Logic minimization is therefore a requirement if high fault grade scores are desired.

The functional simulation vectors may have been developed for an earlier technology version of the array circuit or may be developed from scratch. They need to be constructed in pages (AMCC uses a 4K or an 128K page depending on the tester), begin with initialization of the array, and initialize periodically within the page between test modules.

Begin by initializing every I/O pin (preferred initialization is within 25 - 100 simulation steps, depending on array size). Proceed to "home" the circuit

For testability, a master reset or master set is desirable since it will allow a circuit to be placed in a known state quickly. For circuits that combine reset or set with non-resettable logic, the flip/flops and latches that are not cleared by the set or reset should be initialized after the set or reset has executed and the components settled. A circuit will need to be placed in a known state between groups of tests, at tester page boundaries and before any long or complex test.

Functional simulation execution

Functional simulations must be done for the maximum and minimum worst-case timing and are sampled with a step long enough to ensure that all changes caused by the controlling data or clock signal have stabilized. (AMCC uses a step of 100ns.) The rule of thumb is to measure the longest path in the circuit, compute its worst-case maximum time delay, add 50ns and round to the nearest 100. For BiCMOS and bipolar arrays, 100ns is more than adequate.

The 100ns step size equates to 50MHz, the limit for the SENTRY tester. Different vendors may specify different step size approaches but the necessity of all signals being stable will remain.

Functional simulation results for the maximum and minimum libraries should be compared as a check on hazards and races. The results for the minimum library should match those obtained with the maximum library. If they do not match, stop and evaluate why they do not.

Table 2-10 Functional Simulations

minimum worst-case maximum worst-case
sampled sampled

Simulation outputs

Each simulator produces a data file or a list file that represents the signals the designer specified and the time step at which they were recorded. Most provide a waveform of the results as well. The formats of these output files are not standardized. To submit them to the array vendor, some reformatting must take place.

Reformatting simulation outputs

To allow vector format checking and to simplify test transfer, AMCC developed the AMCCSIMFMT (AMCC simulation format) program. It reformats the output of the logical simulator into a form acceptable to AMCC test and to programs that need to read the files. (This standard format allows the simulation sampled output file to be used as a data input file to other software.) Each supported EWS and netlister has a unique AMCCSIMFMT program.

Vector Rules Checking

The AMCC Vector Rules Checker (AMCCVRC) can be run against any AMCCSIMFMT (AMCC Simulation Format) sampled simulation output file from any simulator. AMCCVRC will issue a count of the number of test vectors and simulation vectors for the particular file being scanned.

AMCCVRC will check for: missing primary I/O signals, missing 3-state or bidirectional enable internal signals. It will identify differential signals, verify that related clock and data signals do not change in the same vector (race conditions for the tester), check the number of simultaneously switching outputs per vector against some established limit, look for internal signals that should not be present, and print a summary of warn-ings and errors.

2-5 Using A Formatter For Simulation Output

AMCCVRC will also identify primary signals that did not change in both directions during the vector set (toggle test). It produces a report and error listing called AMCCVRC.LST that is a required part of the design submission package.

Every maximum worst-case functional simulation file must be processed through AMCCSIMFMT and AMCCVRC.

simulator output ----> AMCCSIMFMT formatter --->amccvrc.lst

Fault grading

There are fault grading programs that score the vectors as to per-cent faults covered. There are a number of fault-grading packages appearing on the workstations and on mainframes.

Fault-grading is used to verify that the simulation bit vectors sufficiently exercise nodes within the circuit to assure that the outgoing product matches the customer specification.

If an array vendor does not support a particular package, it is likely that the software will give misleading fault grade scores. Fault grade scores depend on the modeling approach used as well as the vectors themselves. Most fault-graders need a file or support program to reduce errors due to global ground not switching, VCC, VSS or VDD not switching, or a terminated output not switching and other, similar exceptions.

Insufficient fault coverage as determined in a fault grading analysis may require the addition of vectors to the graded set.

Functional simulation vector fault-grading can be performed at AMCC using the LASAR 6 simulator. AMCC looks for scores based on the interconnect nets and not on the internal macro component interconnect links. MSI macro modeling (and whether the macro is hard or soft) will affect fault grade scores. AMCC recommends the creation of enough vectors to achieve a fault coverage of 90% or higher.

simulation stimuli and netlist ----> fault-grader ---> report grade

At-speed simulation

In addition to function simulation, the designer must perform some at-speed verification of circuit operation. One method is to perform a simulation that is executed at the specified maximum frequency of operation of the circuit with timing checks enabled.

At the minimum, these vectors should cover the critical performance paths of the circuit and may cover the entire circuit.

The at-speed simulations are run using Front-Annotation. The Front-Annotation results are not to be considered to be a specification of the final results. The at-speed simulation is re-executed when Back-Annotation files are available.

For conventionally specified array series, at-speed timing analysis is done with the worst-case military or commercial (maximum) and with the minimum library.

At-speed simulations are run with the print on change option for the simulator (print_on_change, -c, list -change, etc.), monitoring the same signals monitored by the functional simulation. Because these are complex to evaluate, they are also performed in the sampled mode. They are run using the maximum library and the minimum library.

Table 2-11 At-Speed Simulations

minimum worst-casemaximum worst-case

Timing Verifiers - An at-speed option

If they are supported by the array vendor, timing verifiers can be substituted for at-speed simulation. Not all timing verifiers are supported by the array vendors even if the corresponding simulators are supported. (The Valid timing verifier is the only one currently supported by AMCC and then only with certain libraries.) Check with the array vendor.

Verifiers can run min-max analysis against either the maximum or minimum delay library. The min-max spread is the process, temperature, and voltage variation for the library and is about 10-40%, as specified by the vendor. This type of analysis can highlight spikes, ambiguity on clock paths, and marginal timing performance.

Supported and non-supported EWS features

Timing verifiers emphasize the need to communicate clearly with the array vendors. When evaluating an EWS or netlist purchase, consult the intended array vendors for a list of systems and system features that the target libraries support before committing to a design approach. The EWS system may have software for which the vendor has not created models, rendering that software useless without extensive further development.

There is a growing pool of independent workstation tool suppliers. For these packages, the array vendor must also be consulted before assuming that they can be used. Some of them alter the netlist that the vendor may be using as input to the layout system, destroying the circuit interface.

Always refer to allowed equipment and EWS configuration supplied by the target array vendors. Consult with them before starting a purchase or a design.

Create the AC test simulation vectors - Optional

AC tests are optional and may be written to check either propagation path delay in a non-memory path or external set-up and hold time for memory elements. Both rising and falling edges should be checked.

AC test simulations may be concatenated into one simulation file provided clear documentation of start and stop time addresses are provided. Each test (one pair of input-output pads, one edge direction) must initialize the circuit so that the test can be performed, provide the stimuli and run until the effect of the stimuli is seen at the circuit output.

AC test simulations are run using the maximum and then the minimum library. In each case, run once for sampled results and once for print on change.

AMCC performs only path propagation delay AC tests. For older AMCC arrays, there is a limit of 20 tests over 10 paths, with bus lines handled as multiple paths. AMCCVRC is used by AMCC customers to screen AC Test simulation vectors.

Table 2-12 AC-Test Simulations

minimum worst-casemaximum worst-case

A.C. Speed Monitor

The AC speed monitor that AMCC built into the Q20000 Series base arrays removes the requirement for customer-generated AC test simulation vectors. This on-chip device will be added to all future arrays.

The basis of the AC monitor is a 9-stage ring oscillator followed by a 2-stage divide by 4 counter. Each stage uses 100 mils of second and third layer metal to evaluate metal loading. The accuracy of the counter is 0.005% up to 100MHz.

The AC speed monitor uses two pads, a power supply pin and the output pad, that are bonded out to external package pins. (See Figure 2-6.)

Figure 2-6 AC Speed Monitor - Q20000 Series Arrays

Parametric testing - Optional

Parametric testing for VIH, VIL is optional. There are several different methods of setting up a parametric simulation. One approach is the use of a parametric gate tree, where all circuit inputs (clocks and set and reset included) are treed by NOR, AND or OR gates (SSI logic) to a single output. The cost is the number of internal cells needed to implement the gate tree, one output and an added load on the primary input signals.

The vectors are the minimal test sequence (100% fault coverage) for that gate tree. A minimal sequence changes one input per vector and the output toggles every vector. Every input is switched from 1-0 and from 0-1, one by one.

The parametric vector set is combined with the functional simulation vector set for fault-grading.

Parametric simulation is run once, using the maximum worst-case library and a sampled output. The vendor may require that the minimum simulation also be run. AMCCVRC can be run to check parametric testing simulations.

Table 2-13 Parametric Simulations

minimum worst-case maximum worst-case
sampled sampled

Jump to Beginning of this Chapter (Chapter 2)
Continue to Next Section in Chapter 2

For information about this file or to report problems in its use email dewhite@best.com - no spamming

Copyright © September 1996, July 1998 Donnamaie E. White - White Enterprises