ACM Home Page
Please provide us with feedback. Feedback
High level design automation tools (session overview)
Full text PdfPdf (81 KB)
Source ACM Annual Computer Science Conference archive
Proceedings of the 1985 ACM thirteenth annual conference on Computer Science table of contents
New Orleans, Louisiana, United States
Page: 73  
Year of Publication: 1985
ISBN:0-89791-150-4
Author
Scott Davidson  AT&T Engineering Research Center
Sponsor
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 2,   Downloads (12 Months): 5,   Citation Count: 0
Additional Information:

abstract   index terms  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/320599.320609
What is a DOI?

ABSTRACT

As VLSI circuits become more complex, traditional design methods and tools have become inadequate to handle the job of assisting a designer in producing a correct design in a reasonable amount of time. New tools that support top down design techniques must be used. Checking the functionality of a large VLSI design is analogous to checking the correctness of a large software design, but other factors, such as testability and manufacturability must also be considered. This session presents some work done in designing tools to support the higher levels of this design process. First we identify some of the stages in the design of VLSI. The first paper, by Agrawal and Poon, gives one view of the VLSI design process, with emphasis on the manufacturability of the resulting design. Once the functionality of the system has been specified, the architecture of the system is specified as an interconnection of high level blocks described behaviorally. This architectural level design is then refined into a functional level design. A design at the functional level consists of behaviorally defined blocks usually smaller than blocks at the architectural level. Examples are memories, registers, ALUs, etc. (The reader should be warned that there is no generally accepted terminology to describe these refinement levels.) Blocks at the functional level are well defined in the sense that they can easily be refined into a design at a lower level, often through use of a library of descriptions of functional level components. Simulation is extremely important in assessing the correctness of a functional level design. The functionality of the simulated circuit can be checked against higher level specifications, and some high level timing analysis can be done. An example of a functional simulator is HELIX, described by Coelho in the second paper. The next step is gate level design, using either logic gates or gate array macros as primitives. Gate level simulation done here offers a more detailed look at the detailed function and timing of the circuit. Stick level and detailed timing simulation is done after gate level design. We consider these as well as layout and routing as low level design issues, and beyond the scope of this session. More and more of the cost of digital product comes from testing, making sure that what is manufactured works according to specification. This is done by applying test vectors to the product. These vectors are evaluated by doing fault simulation of the design. Fault simulation has been traditionally done at the gate level. For complex designs this has become impractical because of memory requirements and extremely long simulation times. The solution to this problem is to do fault simulation at a higher than gate level. However, only gate level fault models have been widely accepted as accurate. Simulating some areas of the circuit at the gate level and the rest at the functional level allows detailed fault simulation of regions of interest to be done quickly. The third paper, by Rogers and Abraham, present a fault simulator that allows this simulation technique.