This paper describes integrated circuit design methodologies. It is based on 10 years of performing and observing integrated circuit design, as well as building and then using computer-based integrated circuit design aids. This is a view from the trenches, in that it is mostly based on local observation of design groups, rather than a survey across the industry. Much of the work and observations were performed in a research laboratory setting, although some of it was performed in a development environment subjected to the time pressure of product design. This paper is proselytizing a particular methodology, which has been found to be very efficient, and describes the design aids required to support this methodology.

In this section we set the context of discussion more concretely by describing the methodology of a completed design. We use this example in following sections to illustrate specific points. The example is a memory controller which connects a high speed, split transaction (address and data) bus to a RAM bank. None of the details of the requirements for the design nor the details of the implementation are of interest here. We examine the methodology, illustrating the tools used, and the order in which they were used.

Prior to writing the requirement document for this chip an overall system architectural specification was written. This upper level design included the structural decomposition of the system and so defined the basic timing and signalling requirements for the memory controller.

Figure 2 shows the methodology. The first step is writing the chip requirement specification as illustrated in detail in figure 3. A 4 page specification describes the general requirements of the chip. It indicates the amount of RAM which each memory controller can handle, the number of banks which can be placed on a bus, and the amount of board area required for the entire memory controller subsystem. It also specifies which of the bus transactions must be dealt with by the memory controller and gives a very abstract decomposition of the implementation of the chip.

The next step in figure 2 is the RTL design of the chip. The RTL design process is further decomposed in figure 4. During this design period the technological constraints were factored into the design by the designer's intuition of the space-time cost of each of the primitives.

With the completion of the RTL schematic, it is possible to verify the integrated circuit design as part of the overall system schematic. This process is illustrated in figure 5.

In parallel with the system simulation, the physical details of the chip implementation are filled in as shown in figure 6. The memory controller consists of a data path and a collection of random control logic. The data path requires more detailed physical design as illustrated in figure 7. The data path design consists of creating a set of tiles which fit together tightly in an arrangement specified by the designer. Each of these tiles has a transistor level schematic and a corresponding layout. Critical paths through the data path are simulated with Spice to keep control of the performance constraints given in the design requirements document. Some low level error checking in the form of structural comparison of layout and schematics as well as geometric design rule checking is performed.

Once the low level details of the data path are completed, the rest of the schematic can be modified to include the information necessary for the layout synthesis tools. This consists of dividing the chip into the standard cell and data path areas, defining the routing blocks which connect them together, and specifying the pad assembly and routing. After these modifications are made, the design is simulated with the design verification test vectors to ensure that the rearrangement of the schematic to include the physical synthesis information has not perturbed the functionality of the design. Layout generation is followed by comparing the layout to the schematics, as a check of the physical synthesis tools, and geometric design rule check, as a check of both the manually and automatically synthesized layout.

In parallel with getting the details of the layout correct, the chip's timing performance is checked by a critical path timing analyzer. All feedback paths due to errors discovered by any of the checkers result in modifications to the schematics, in the case of design errors, or modifications to the synthesis tools in the case of design aid bugs. The final connectivity check shown in figure 6 is solely to catch bugs in the design aids. It checks that all of the rectangles emitted by the router which are supposed to intersect each other, in fact do so.

Finally we return to figure 2 where we see the design exit the portion of the design flow that we are discussing in this paper, and go on to fabrication and test. In parallel with fabrication and testing, the logical operation of the chip is documented. When the chip returns from test, the final performance numbers, and D.C. parameters are inserted into this documentation.

In this section we derive the tools required to allow the methodology presented in the example to be followed. Of course we did not perform the design first and then build the tool suite. In fact, the tool development was driven by this design, so sometimes the tools were developed before they were assumed by the design, and sometimes the design assumed new tools before they were actually implemented.

These consist of:

Of course, all of these tools have to be tied together and driven from a single design source. Many of these tools are standard, some are available, at least in experimental versions, from several sources, and some are unique to our tool suite.

The key enabling features which we believe to be unique to our system and that increase designer productivity include:

In this section we evaluate the methodology and tools described in the previous two sections according to the criteria established in the introduction. We will deal with each of the criteria in turn, describing how the existing methodology and tools succeeded or failed in satisfying them.

This is at the back of the paper because there is little literature discussing methodology per se. This is probably because it is difficult to make definitive statements. Most descriptions of methodologies are in the context of specific design examples with little generalization of the lessons learned in a specific example. Methodologies tend to evolve in response to needs and enabling technologies rather than being a focus in their own right.

[Weste et al.] talk about design approaches as if behavior, structure, and physical design can be done independently. Their description of current design approaches do not include any feedback paths from lower levels to higher levels of abstraction. This work contains a number of case examples.

In the dynamic time warp processor example, the "functional" description contains many schematics that look like structure. However, they say they wrote a functional simulator. Why did they do this? Was their simulation technology so inferior they had to hand recode for speed?

The single chip 32-bit CPU example talks about top down in one breath and in the next about doing all levels of design in parallel. Clearly there is some confusion about the meaning of top down. They seem to mean hierarchical divide and conquer, rather than successive refinement, which definition assumed in this paper.

[Rubin] talks about "refinement" which proceeds "from the abstract to the specific"; also "Although design rarely proceeds strictly from the abstract to the specific, the refinement notion is useful in describing any design process. In actuality, design proceeds at many levels, moving back and forth to refine details and concepts, and their interfaces." This is design by attacking the greatest uncertainty. Although some people may be working in parallel, collectively they should be working on the most uncertain aspects of the design, i.e. where the greatest risk is. When the uncertainty, or risk, is reduced to zero, then the design is completed.

There is also a good discussion of design as the process of constraint satisfaction. It further describes top-down vs. bottom-up, and indicates they are almost always mixed in a real design. Many people have realized that design is always a mixture. In this paper we are making the point that behavioral descriptions of complicated implementations are not worth the effort; with sufficiently abstract structural descriptions, and sufficiently efficient means of simulating them, it is better to go straight to the structural description.

[Sequin] talks about design proceeding both top-down and bottom-up, and then meeting in the middle; "Yo-Yo" iteration until "the optimal path linking architecture to technology has been found." He also talks about the CAD system virtuoso, someone who can move through the maze of design options with a set of tools with great expertise. He also mentions the designer as tool builder and draws a development spiral. Both of these apply to what we have done here. You must be a virtuoso to use our tools effectively, and the tools were mostly built by designers, except for portions which were well understood at the beginning.

[Trimberger] suggests that the complete description of the design in a behavioral form is required, although he tempers his statement with suggestions that large variances from this design flow are normal.

[Meade et al.] talk about "top down" design with the caveat that the architect must have a full understanding of lower levels of the hierarchy. However their discussion hardly mentions tools to support a methodology. In the intervening decade since this work was published, tools have become a central part of any methodology, while the particular implementation technology has left center stage.

[Glasser et al.] expand on the notion that a holistic view of design is necessary for significant invention, while abstractions which compartmentalize our thinking are the basis of any methodology. Unfortunately, they treat the description of methodology purely by describing an example. The central role of CAD tools is missing from their presentation.

This complements Sequin's view of the CAD virtuoso. As in music, the virtuoso plays his artistic notions within a style of music known to the performers. Within the capabilities of the instruments available, the CAD performer plays with his architectural notions within the constraints of the style his group is used to, and the tools available to him. Sometimes a new notation, or a new instrument, is needed, but in general, one plays out a design in the context of existing styles and tools.

[Niessen] describes criteria for VLSI design methodologies. These include:

He also goes on to say that the primary concepts of design methodology are abstraction, repetition, and the use of past experience. His article is a prescription for CAD tools needs, while this paper is a report on results once the CAD tools have been built.

[Trimberger et al.] talk about a design methodology focused upon custom integrated circuits. Suprisingly timing analysis tools are ignored. The focus is upon functionality and the space aspects of layout. They make statements such as "The functional and geometrical hierarchies must match because the logical connection, the interface between functional units, is precisely along the geometrical interfaces." This may be true in their methodology, it is certainly (mostly) true in ours, but it is not true as an universal statement.

The problem with most of these design flows is that they assume some real split between behavioral description and structural description during design. There is none.

[Newton et al.] refer to parameterized circuit modules. These are not capturing design at the same level of abstraction which the parameterized logic library does. They are directed towards array structures rather than arbitrary logic networks.

The top down methodology doesn't work well because it is cumbersome, in the sense of having to prepare far more description than is required to fabricate manufacturing tooling, and it delays technology constraint satisfaction too long. The ASIC, or bottom up, methodology doesn't work well because it is cumbersome, in the sense of having to build many low level details manually, and delays application constraint satisfaction too long.

In this paper we have described a methodology that compromises between the top down and bottom up methodologies so that both the application, and technology constraints, can be satisfied while the designer is preparing a minimal source description. This source description is minimal in that it can be automatically translated into the tooling specifications for fabricating the design, and it makes use of design knowledge encapsulated as procedural descriptions. The combination of simultaneous satisfaction of technological and application constraints, and minimal irredundant source capture leads to minimal design time and manpower.

To support this conclusion we have described the methodology of a completed design, and the set of tools which enabled this methodology, then compared the amount of work required for this methodology against the work required by other methodologies. Unfortunately, in the costly and mathematics-free realm of system design, no stronger evidence can be offered.