Last Edit July 22, 2001
RaceCheck is a tool developed by AMCC for verifying that no problems
exist in the test vectors to be used for automated test. RaceCheck incorporates
Teradyne's LASAR 6 simulator into an easily executable form. A series
of translators for getting data from the AMCC generic format into the
LASAR format, and for getting back to the AMCC generic format, have been
The entire process, including running LASAR and checking the results,
has been put into a shell that prompts the user for needed information
and then submits the process to a job queue for actual execution.
RaceCheck must be run using all functional, parametric, and AC test patterns
intended for use on AMCC's automated test systems.
Timing verifiers are an alternative timing analysis tool that is available
on most workstations. They are used to predict circuit performance under
real-time conditions and are an alternative to the at-speed simulation.
Example verifiers are the Valid timing verifier, DTV from Dazix, and QuickPath
One problem with the verifiers is that they do require different models,
increasing the effort required to add an array library to the system.
A different model library and different annotation files may be required
for the timing verifier than for the simulator on the same system.
A timing verifier on one workstation supported by an array vendor does
not guarantee that another workstation supported by the vendor has a supported
verifier. An array library may exist for the simulator and not for the
timing verifier on any given workstation.
The timing verifiers that can be used, if any, will be determined by
the array vendor.
Hardware emulators are beginning to be adapted into the workstation arena,
driven in part by the increasing size of the arrays and their simulations.
Heavily populated large arrays (over 5000 gates) can saturate a workstation.
When combined with a large vector set, the simulations can run for days
on some workstations or cause back-up on a mainframe. Hardware emulators
can reduce the simulation time to hours or minutes.
Emulators may be part of the add-on hardware of a native system or they
may be independently sourced systems. Example systems are the MegaLogician-Gatemaster
MDLS for Dazix and IKOS, capable of being driven from a Dazix, Mentor
or Valid front-end, among others. This cast of players is in a high state
of flux. Always check into what is currently available when evaluating
The more user-friendly the simulator input process, the more likely the
engineer will make use of the tool. At this time, the set-up required
for some emulators takes longer than the final simulation execution time!
That is expected to change as more users are forced to acquire simulation
A hardware emulator can be used if the array vendor supports the emulator.
Another driving force behind the evolution of the hardware emulators
is the need to have improved AC power computations. Using an emulator
and a benchmark vector set designed to reflect the circuit usage, a better
evaluation of macro or gate switching frequency can be obtained resulting
in a closer estimate of expected AC power dissipation. The problem complexity
is beyond the available simulators. Note that the accuracy obtained even
with an emulator will depend on the accuracy of the vectors analyzed.
No single simulator can handle all problems and circuit complexities
with equal ease. Circuit structures such as reconvergent fan-out and tight
rise-fall timing ambiguity analysis are handled at varying levels of accuracy.
The idea of a "golden simulator" is an attempt by array vendors to guarantee
that a known level of accuracy and simulation capability is used on all
in-coming designs. It is also one way of standardizing the submission
Dial-up simulation is offered by several array vendors and being considered
by others. Using dial-up, the different array designers could access the
selected array-vendor-resident simulator. It allows small companies to
take advantage of a mainframe simulator without a significant hardware
investment. The requirements would be that the user have a VT100-type
terminal for batch operation or a full graphics station for interactive
place and route.
Questions To Ask
A designer selecting an array must have a clear understanding of the
design submission process required by that specific vendor. The number
of simulations and their format will vary with the vendor and with corporate
policies of the designer's company. Questions that should be asked before
design start are shown in Table 8-1.
During design validation, thorough simulations are required. The types
of simulations that are specifically required for design submission will
vary from vendor to vendor. There are four basic groupings currently required
or allowed by vendors:
- wafer-sort, packaged-part test vectors
- timing verification at-speed
- AC test
These four will be discussed since they represent a sufficient set for
design submission. Additional simulations or slight variations may be
required by various array vendors or quality assurance managers. Understanding
these four basic groups will provide a basis for understanding any other
simulations that may be required for a design.