Logic Design for Array-Based Circuits

Copyright © 1996, 2001, 2002 Donnamaie E. White

• 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
  • Intr oduc tion
  • 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

Introduction

Simulation is a design synthesis - design validation - design verification tool. It can involve the functional module level, the entire array or an entire PC board (arrays and other devices). The array vendor is responsible for the detailed Spice-level modeling of the macros, i.e., modeling at the basic device level of transistors, resistors, diodes, with parametrics generated by characterization of the array process.

As a rule, the designer does not need to evaluate the circuit to that level of detail. Exceptions are those circuits with strict path matching require-ments. In that case, a partial circuit involving the paths in question is evaluated at the discrete level. This is usually done with the support of the array vendor.

Before design start, a simulator can be used to:

• evaluate the array series
• evaluate different implementations of critical or complex structures

Partial and checkout simulations are usually not submitted to the array vendor at design submission although this use of the simulation tools is an important step in automation of the design synthesis process. These simulations are usually in the "quick and dirty" class in that they are run to appease the designer and often not documented. (This is not intended as approval for the lack of procedure; it is merely a statement of what occurs.)

Any simulation done to "check out" a design implementation, partial or not, should become part of the design notebook and be correctly documented.

During design synthesis, simulation can and should be used to:

• debug the logic design itself
• debug the implementation of that design - functional performance
• evaluate the timing performance of the design implementation
• generate test vectors for prototype and production testing

Simulations used to debug the complete circuit, to check functional performance and some of the timing analysis vectors can often be used in the creation of the complete test vector set for wafer-sort and packaged part testing.

Test vectors are generated from simulator output files. Before simulations are generated for an ASIC array, the designer needs a basic understanding of the testing problem. This encompasses:

• why the vector set is needed
• what is being tested by the vendor
• what is not being tested by the vendor
• what could be added to the testing done by the vendor if added to the contract

In addition, the designer must be aware of the limitations imposed by the array vendor that may be tied to a specific tester. They may be driven by the specific simulators supported by the vendor. A vendor may require that all submitted simulations have been run on a specific "golden simulator".

Simulation output files may need to be reformatted before submission. Such reformatted files are then processed as data by the array vendor using a test generation program which may add tester-specific control vectors to handle bidirectional and three-state enable signals.

The designer may have access to an automatic test generator (ATG) and may have done the proper design for test (DFT) that supports the use of the ATG. The vectors produced by this method may still need to be processed to assure that the vectors are in the proper format for the array vendor and meet the required rules. Check with the chosen array vendor to see if ATG is supported.

Copyright @ 2001, 2002 Donnamaie E. White, White Enterprises
For problems or questions on these pages, contact dew@Donnamaie.com