An integrated circuit design methodology transforms vague design requirements into a collection of pattered layers which comprise the fabrication tooling, a set of test patterns which verify the design, and documentation which describes the operation of the circuit (Fig. 1).

1. Bottom-Up

2. Top Down

In this section we review a representative sample of the existing literature and indicate the contributions of the current work.

Weste1 includes a flow graph of current and ideal design approaches and an enumeration of automatic and manual synthesis mechanisms. Isolated from this abstract discussion is a series of CMOS system case studies. One such case study uses top-down in the sense of hierarchical divide and conquer rather than our definition of top-down as successive refinement.

Many people have realized that design is always a mixture of top-down and bottom-up methods. Rubin2 has an abstract description about "refinement" which proceeds "from the abstract to the specific"; "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". There is a good discussion of design as the process of constraint satisfaction, which further describes top-down vs. bottom-up, and indicates they are almost always mixed in a real design.

In this paper we bring together the abstract and concrete discussions of Weste and add a case history to the abstract discussion of Rubin.

Trimberger et.al.3 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 the assumption that the physical and logical hierarchies match, just as we do. We explore the implications of this restriction.

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

We claim 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.

Meade and Conway5 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. Our example emphasizes this central role of tools.

Niessen6 describes criteria for a VLSI design methodology. These include.

He defines the primary concepts of a design methodology to be abstraction, repetition, and the use of past experience. Here we describe much more detailed criteria for a good VLSI design methodology.

The definition of a good design methodology depends upon a large number of contextual factors. The complexity of the design, the background of the design engineer, the history of the design group in which he is working, the cost and performance goals of the design, and the available computing resources are just a few of the factors which must be considered. Describing a good methodology is further complicated by the fact that every design has a different detailed design methodology. Each individual design poses different problems which need to be solved in an unique manner. Even though composing a methodology for any particular design is so context dependent, a number of criteria can be stated that are reasonably universal.

Minimal source leads to fast design times. If the designer has to reenter some design information several times then the potential for error grows and the cost of changing the design, even in the absence of errors, also grows. The source is minimal when a design is entered at the highest level of abstraction possible that is consistent with available automatic synthesis techniques, and no higher. The level of abstraction should be high, because more abstract descriptions require less source. It should not be any higher than automated synthesis techniques can handle, because the designer would then have to manually translate to the level that can be handled by automatic synthesis, leading to redundant source.

Technology constraints affect a design at least as much as the behavior specified by the design requirements. Frequently the intended behavior is mostly defined by what is possible, rather than what is required. A good methodology relies on the intuitive abilities of the designer to find a simultaneous solution to the technological and application constraints. Humans perform such tasks well; to the greatest extent possible the design aid system should take care of everything else; especially keeping track of all of the details, which is a task that computers perform well. Early evaluation of design feasibility by determining the fit of the solution to the set of constraints is important.

Fast turnaround for small changes is just as important to hardware designers as it is to programmers. Since it is impossible to enter a design completely correct the first time, it is important to make it easy to go through the change and evaluate cycle.

During the forseeable future every significant design will have some amount of structural description before reaching elements that can be automatically transformed into artifacts. Thus, pure behavioral descriptions are not useful, and a good set of tools must have a good structural description mechanism. More strongly, most design is currently done by structural decomposition. As logic synthesis improves this may become less true, but it is certainly true now.

Even though most design is structural, it is still useful to describe some portions of a design behaviorally. Finite state machine synthesis is sufficiently mature to be considered a primitive in the description. Some portions of a design, such as memories, are so simple to describe behaviorally, relative to their structural descriptions, that behavioral description is clearly best during initial design. Simplified behavioral models are also useful during debugging to check consistency between abstract behavior and concrete implementation.

Many portions of a design are only slight variations on a basic theme. Counters are a classic example in which the carry propagate network is slightly different depending upon the number of bits. It should be possible to capture this design knowledge in a manner which allows its reuse in many contexts.

We have described criteria for evaluating the efficacy of a design methodology.

Each of these criteria imply desires for the tool set which supports it. To have minimal source one would like the best automated synthesis tools possible. It must also be possible to extend the description mechanisms in ways specific to the current design, i.e. the tool set must be easily extended. Early design evaluation implies tools which can analyze a partial design. Fast turnaround implies that the amount of work done by the tool set, in response to a change, should be proportional to the size of the change, rather than the size of the design. Reusable descriptions imply a method for parameterizing the description mechanisms.

In this section we describe the methodology of a completed design. The example is a memory controller which connects a high speed 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.

Fig. 2 shows the methodology. The first step is writing the chip specification as illustrated in detail in Fig. 3. This stage of design simply used a text editor.

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

The RTL design time is dominated by the preparation of schematics and debugging them with a simulator. The behavioural models and test programs are written in the local standard algorithmic programming language. With the completion of the RTL schematic, it is possible to verify the integrated circuit design as part of the overall system schematic, as illustrated in Fig. 5.

This step uses the same schematic and simulation system as was used for the RTL design. The invariant checkers are written in the same manner as the RTL behavioural models.

In parallel with the system simulation, the physical details of the chip implementation are filled in as shown in Fig. 6. The design is incrementally enhanced until it meets the space-time constraints of the implementation technology. 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 Fig. 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 is 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 again 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 finished 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 correcting the details of the layout, 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 Fig. 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 Fig. 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 evaluate the methodology and tools of the example according to the criteria established earlier.

1. Minimal Source

2. Early Design Evaluation

3. Fast Turnaround for Small Changes

4. Structural Description

5. Behavioral Description

6. Reuseable Design

The top-down methodology doesn't work well because it requires more description than is necessary to fabricate manufacturing tooling, and it delays technology constraint satisfaction too long. The bottom-up methodology doesn't work well because it requires manual preparation of many low level details 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 leads to minimal design time and manpower.