Logic Design for Array-Based Circuits

Copyright © 1996, 2001, 2002, 2008, 2016 Donnamaie E. White , WhitePubs Enterprises, Inc.

• Table of Contents
• Preface
  
• Overview
  
• Chapter 1 Introduction
  
• Chapter 2 Structured Design Methodology
• Chapter 3 Sizing the Design
• Chapter 3 Appendix = Case Study in Sizing a Design
• Chapter 4 Design Optimization
• Chapter 5 Timing Analysis for Arrays
• Chapter 6 External Set-up and Hold Times
• Chapter 7 Power Considerations
• Case Study: DC Power Computation
• Case Study: AC Power Computation
• Chapter 8 Simulation
  • Introduction
  • Simulators - The Tools
  • Non-Native Simulators
  • AMCC's Race Check
  • Timing Verifiers
  • Hardware Emulators
  • Golden Simulators
  • Design Validation
  • Wafer Sort/Packages Part Sort Functional Simulation
  • Fault-Grading
  • Testability Analysis
  • Simulation Rules
  • At-Speed Simulation for Timing Verification
  • AC Tests
  • Parametric Vectors
  • Gate Tree - Any Circuit
  • Hazards
  • Structural Hazard Types
  • Functional Hazards
  • What is Required to Fix Race Problems
  • Exercises
• Case Study: Simulation
  • Introduction
  • The Schematic
    • Output Enable
    • Clock
    • MUX Enable
    • Design Checks
    • Annotation
  • The Simulations
    • Functional Simulation
    • Parametric Simulation
    • At-Speed Simulation
    • AC Test
  • Exercises
• Chapter 9 Faults and Fault Detection
• Chapter 10 Design Submission
• ASIC Glossary
  • Glossary A-D
  • Glossary E-K
  • Glossary L-R
  • Glossary S-Z
  • Symbols

Simulation

Last Edit July 22, 2001

AMCC's RaceCheck

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 provided.

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

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 from Mentor.

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

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 emulators.

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 assistance.

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.

Golden Simulators

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 process.

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.

Design Validation

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
• parametric

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.

Copyright © 1996, 2001, 2002, 2008, 2016 Donnamaie E. White , WhitePubs Enterprises, Inc.
For problems or questions on these pages, contact donnamaie@-no-spam-sbcglobal.net