Efficient Structural Design for Integrated Circuits
Richard Barth and Bertrand Serlet
Abstract: A design methodology is the process of transforming design ideas into artifacts. Two different design methodologies have been described for the design of systems with custom or semi-custom integrated circuits.
One is the top down methodology in which designers start with very abstract specifications of behavior, analyze that behavior with the aid of computer-based tools, and then proceed towards the specifications which are actually used to build the system, such as the masks for fabricating circuits and printed circuit boards.
This approach provides a very structured set of events to proceed from the idea to the implementation, and therefore is likely to yield a working system. However, the time and resources it takes to complete all the necessary steps is large. This methodology requires good planning and significant manpower. Moreover, the approach requires many different representations of designs and therefore an extensive collection of sophisticated tools to handle them. Currently a complete suite of such sophisticated tools is not available. Some transformations between these different representations must be maintained manually, adding further to the manpower requirements.
Another approach, the ASIC methodology, is espoused by the semi-custom integrated circuit foundries. It consists of describing the circuits structurally in terms of low level primitives, such as gates, instead of behaviorally.
This methodology is very restricted since its intention is to guarantee that the foundry gets paid, not to guarantee that the semi-custom circuits will actually work in the system for which they were designed. This methodology does not really deal with the integration of circuits into a system at all. That is left to a higher level methodology which is not the responsibility of the foundry, although the foundries methodology requirements can have a serious, detrimental, impact upon the overall system design methodology.
In this paper we define the top down and ASIC methodologies more rigorously, describe the problems with them in more detail and present an alternative methodology that skips the behavioral specification stage of the top down methodology, and also avoids the low level approach of the ASIC methodology. We describe the tools that are necessary to support this methodology and give an example of a large design which used it.
CR Categories and Subject Descriptors: B.6.0 [Logic Design]: General; B.6.1 [Logic Design]: Design Styles; B.6.3 [Logic Design]: Design Aids; B.7.1 [Integrated Circuits]: Types and Design Styles; B.7.2 [Integrated Circuits]: Design Aids; B.m [Hardware]: Design Management; D.2.2 [Software Engineering]: Tools and Techniques; D.2.10 [Software Engineering]: Design
Additional Keywords and Phrases: VLSI, Design Automation, Design Capture, Design Management, Design Methodology, Tool Integration, Extensibility, Schematic Capture, Hardware Description Languages, Abstraction Capture
Introduction
Problem Statement
vague structure to tooling and maybe working prototype for ASIC integrated circuits
do not include architectural tools such as statistical analysis of bus bandwidth
do not include test or manufacture tools (but maybe debug tools), or PCB
will use graph of tools and their i/o relationships as a model, directional coloring of the graph corresponds to a methodology
make strong claim that design, tools, and methodology must be considered together. design as the process of uncertainty reduction (reference?). even the static coloring of our graph is too restrictive during the synthesis process, methodology is something which is defined as things go.
define methodology as the sequence of use of tools or transformations. These tools may be as simple as a piece of paper and a pencil or as complicated as a place and route system
contribution of paper is formal definition of nodes and arcs of graph. perhaps another contribution is defining the design methodology where the library is parameterized and the entire design process is one of successive refinement of a single structural design description so that a structural description can serve for initial, close to architectural, design as well as pulling together the final design.
Maybe we should declare that behavioral descriptions are not a good way to capture designs. They are just additional overhead that could be avoided. The structural solution to a problem intimately influences the problem statement itself so that decoupling the two does not produce any benefit but, rather, just slows things down and confuses things. [Trimberger] alludes to these realities on p. 11. Behavioral design is design without a clear view of the space, power, packaging, etc. constraints that any real solution must have.
Relationship to Previous Work
Gajski's Y chart and Rammig's first chapter are too restrictive, decomposition is artificial.
Methods described in ASIC manuals are too simplistic, good for assurance that the device will pass through the well defined manufacturing interface but not good enough, from a verification standpoint, to assure the device will work in a system, and not good enough from a synthesis point of view to describe how a designer comes up with the description that starts the verification step.
Organization of tools such as LSI Logic is crazy. It is inflexible, has lots of overlapping implementations, is hard to maintain, etc., etc.
Description in [Director et al.] is not formal enough and does not address the definition of multiple methodologies as a directed coloring of a graph. [Newton et al.] is similarly informal.
[Weste et al.]
[Mead et al.]
Tool Graph
In this section we present the graph and define each of the nodes and edges.
Methodologies
describe two extreme methodologies.One is top down design. Other extreme is pure schematics similar to ASIC design practice as described by ASIC vendors such as LSI Logic. Reason why half of ASICs don't work in their intended system.
Top Down Methodology
users perspective
many interfaces, hierarchical
tool perspective (painted graph)
advantages/disadvantages
if the problem is well known so that good planning is possible (i.e. the plans are relatively correct when made), and if lots of manpower is available then the task can be accomplished in less time
Schematic Only Methodology
users perspective
tool perspective (painted graph)
advantages/disadvantages
This methodology starts at a very low level. Picking little cells out of a huge library in order to build up the larger blocks needed requires too much effort at the beginning of a design. Takes too long to get a simulation going and changing things radically takes too long. The approach of providing fixed blocks such as CPU's or specific length counters makes the library
Our Methodology
users perspective
tool perspective (painted graph)
example
Use map cache to illustrate the methodology we have and the nodes in the graph necessary to support it.
advantages/disadvantages
The Future
Missing Nodes in the tool graph, how to do portion of ASICs we have been talking about better.
Add tools so that the graph can be painted better for original problem.
Expand problem graph to cover larger problem. how to do encompass larger portion of integrated circuit design.
Extend towards analog design.
Expand problem graph to cover larger problem. how to do encompass larger portion of system design.
Extend towards architectural and pcb.
References
[Ayres]
R. Ayres, VLSI silicon compilation and the art of automatic microchip design, Prentice-Hall, Inc., 1983.
[Director et al.]
S. Director, W. Maly, R. Rutenbar, J. Shen, D. Siewiorek, A. Strojwas, and D. Thomas, ``Integrated CAD, CAM, and CAT of VLSI Circuits and Systems: The CMU Perspective,'' IEEE Design & Test of Computers, 2(3), pp. 87-100, June 1985.
[Mead et al.]
C. Mead and L. Conway, Introduction to VLSI Systems, Addison-Wesley Publishing Company, 1980.
[Trimberger 1]
S. Trimberger, An Introduction to CAD for VLSI, Kluwer Academic Publishers, 1987.
[Weste et al.]
N. Weste, and K. Eshraghian, Principles of CMOS VLSI Design: A Systems Perspective, Addison-Wesley Publishing Company, 1985.
References To Be Acquired
[Lattin]
B. Lattin, ``VLSI Design Methodology: The Problem of the 80's for Microprocessor Design,'' Proceedings of the Caltech Conference on VLSI, 1979.
[Newton et al.]
A. Newton, D. Pederson, A. Sangiovanni-Vincentelli, and C. Sequin, ``Design Aids for VLSI: The Berkeley Perspective,'' IEEE Transactions on Circuits and Systems, Vol. CAS28, No. 7, July 1981 This is the earlier version of the SRC members only revision.
[Niessen]
C. Niessen, ``Hierarchical Design Methodologies and Tools for VLSI Chips,'' Proceedings of the IEEE, vol. 71, January 1983.
[Trimberger 2]
S. Trimberger, J. Rowson, J. Gray, and C. Lang, ``A Structured Design Methodology and Associated Software Tools,'' IEEE Transactions on Circuits and Systems, vol. CAS-28, no. 7, July 1981.
[vanCleemput]
W. vanCleemput, ``Hierarchical Design for VLSI: Problems and Advantages,'' Proceedings of the Caltech Conference on VLSI, 1979.
LSI Logic Design Handbook - I looked at it. I couldn't find the design signoff checklist which they require before fabbing a design. Nor could I find anything that could be construed as a methodology.
ICCAD - library has very few of these
DAC - there is a complete set of the recent DAC proceedings in the library
Transactions on CAD
Transactions on Circuits and Systems
Transactions on Computers
Transactions on Engineering Management
Custom Integrated Circuit Conference.
VLSI
Design & Test
Computer