 |
 |
|
|
| The next characteristic of design is the use of different views to abstract an object. This certainly applies to electronic design; circuit designers view their work in many different ways. For example, the transistor can be drawn either as a schematic symbol, as a fully fleshed-out piece of geometry, or as a behavioral description in a textual language (see Fig. 1.18). Similarly, an inverter can be drawn as a single symbol with one input and one (inverted) output, as a temporal diagram showing transitions, or as a complete gate diagram with all the transistors and connections that perform the inversion (see Fig. 1.19). Circuitry is often specified with differing views, and these representations combine to form a complete design. This section will discuss three view classes for electronic circuitry: topology, time, and behavior. Also of importance is the maintenance of correspondence among different views, which will be discussed at the end of the section. |
|
 |
| FIGURE 1.19 Multiple views for an inverter: (a) Schematic (b) nMOS (c) Bipolar (d) Temporal. |
A distinction now must be made between the terms "hierarchy" and "view." These terms blur because, in one sense, a hierarchical organization is a view of an object, and, in another sense, a collection of different views forms a hierarchy. Thus there is the physical hierarchy that was discussed in the previous section, which shows how the parts of a circuit are composed; there are many different views of a circuit, each one potentially hierarchical; and there is an organization of these views that is a hierarchy. The first hierarchy is a physical hierarchy and the last is a view hierarchy.
The topology of a circuit is its structure, or connectivity that describes the physical parts. Figures 1.18 and 1.19 illustrate a few topological views, the exceptions being Figs. 1.18(d) and 1.19(d), which are behavioral and temporal descriptions. Each view captures some essential abstraction of the circuit. The most abstract form is the architecture view, in which machine components such as processors and memories interconnect. Lower than that is the component view, in which datapaths and registers connect. This is often used to describe a complete hardware design without giving trivial detail. Below this, the gate view shows all necessary components without precise placement or size. At the bottom, there are layout or mask views that show all the geometry that will be manufactured. Chapter 2 describes these topological views and shows that their ordering is not able to be precisely specified. In fact, there are many other ways to consider the ordering of circuit views [Brown, Tong, and Foyster]. Nevertheless, all these views form a hierarchy in which the more abstract representations are higher than are the more detailed descriptions.
| Temporal views capture the activity of a circuit over time. The most precise view of a circuit's temporal activity is an analog plot of voltage over time (see Fig. 1.20a). Digital logic designers prefer to see their circuit as a more discrete process, so they use a threshold to separate true (or "on" or "1") from false (or "off" or "0"). In addition to forcing discrete logic values, they also view time discretely by presuming transitions to occur instantly (see Fig. 1.20b). |
|
| When multiple signals are described temporally, there is often a need to see the transitions and compare their start and end times (see Fig. 1.19d). When the switching time is all that matters and the direction of the switch is unimportant, timing diagrams are drawn with both transitions overlapped (see Fig. 1.21). |
|
To relate circuit activity temporally, the designer must understand how each change affects subsequent activity in the design. A circuit that allows each value to flow directly into the next with no synchronization is an asynchronous circuit. Such circuits can use special structures to let each part of the design inform the next part when it is done [Seitz].
More common, however, is the use of clocks, which broadcast values
at regular intervals.
These values force the circuitry to function in lock-step fashion, making
it synchronous.
A popular clocking scheme is the two-phase clock, which consists of
two signals called  1 and 2 that alternate being
on and off (see Fig. 1.22).
These values are generally nonoverlapping such that they are
never both on at the same time (one must go off before the other goes on).
Other clock schemes include single clocks and even complex combinations of
six clocks.
There can also be major and minor cycles, with one clock
signal changing many times during one pulse of another clock signal.
|
|
One of the most difficult problems for designers is the visualization of temporal relationships. The many synchronous and asynchronous methods of design help to alleviate the problem somewhat by allowing temporal assumptions to be made. A common assumption is that all activity triggered on one phase of a clock will complete during that phase. However, designers are still responsible for ensuring that the clock phases are of reasonable length and that there are no pathological pieces of circuitry that demand excessive clock time. When circuit activity in one clock phase extends into the next phase, clock skew problems arise. Although skew can be used to advantage when properly designed, it can also cause race conditions in which supposedly stable values are still in transition, causing unpredictable results.
Another source of trouble is the delay of clock signals as they propagate through the chip. This may cause the phases to overlap and the expected clock windows to be wrong. Designers must run the clock lines in parallel to ensure identical delays. Today's CAD systems do not help much with the problems of time and often leave the final analysis to the designer.
In addition to showing how a circuit actually acts, there must be ways of describing its expected behavior. A behavioral view of a circuit helps designers to visualize abstractly the interactions among elements of the circuit. Behavior shows both the topology and the temporal activity of a circuit, and is the highest level of description available.
Behavioral descriptions express topology in many ways, such as the algorithmic descriptions of Fig. 1.18(d). Hardware-description languages provide convenient shorthand tools, such as ways of aggregating individual signals into integers and buses. Also common are iteration constructs and macros that allow similar behavior patterns to be expressed concisely. Of course, the behavioral description should be able to handle the dynamic nature of a circuit.
Behavioral descriptions can express time in absolute or relative ways. Absolute event specification is measured from the start of an activity. An example is the claim that at time zero, the circuit is in a given state and at time t, the circuit is in some other state. More common are relative event specifications because they combine easily. An example is a shift cell the output of which at the present time cycle is defined in terms of the input value during some previous clock cycle.
Temporal relationships can be expressed behaviorally with logic operators that have formal properties. By expressing events and state in terms of these operators, the designer can specify precise temporal order. For example, the unary operator eventually implies that something will take place in the future and the binary operator prerequisite implies that one event must occur before, or as a prerequisite to, another event. Combining these operators in proven ways allows an overall circuit analysis to be derived from the specification of subcomponents. This static analysis is the basis of some simulators and timing verifiers.
Behavioral descriptions are often specified textually because they are algorithmic in nature. The use of such descriptive languages becomes a task in programming, with all of the ensuing problems of debugging, documentation, and understanding. However, since designers usually prefer graphical layout methods, there is no reason why behavior should not be specified in the same way. Thus the graphical representations in Figs. 1.18 and 1.19 are popular ways of describing behavior. For the same reasons that it is good to have graphic layout, it is also good to have graphic behavioral descriptions. Furthermore, since simulation is such a common way of testing behavioral specifications, the graphic display is best suited for monitoring that process. This is because many parts of a circuit may run in parallel, so only a spatial display can effectively capture the activity.
The drawbacks of graphical behavioral specification are the same as those of all graphic design. The lack of portability, verbal documentation, and parameterization can all be overcome with more expressive graphics languages. The expense of a graphics display, which is no longer as great as it used to be, is simply worthwhile given the advantages of graphic editing and can be defended only by saying that you get what you pay for. However, there is an overall problem concerning graphic programming: the lack of much theory or experience. Most programming languages and their studies have been textually based. Any reasonable graphical behavior language must have all the facilities that programmers have come to expect. Until such a language is available, textual hardware-description languages will be the most common.
A fundamental problem in VLSI design systems is the maintenance of correspondence among different views. Designers rarely want to work at the lowest layout levels, so they often begin by specifying their circuit at the architectural or behavioral view. Conversion from more abstract descriptions to less abstract descriptions can be done in a number of ways; for example, by using silicon compilers to convert from more abstract behavior to less abstract layout. However, once converted, there is rarely any connection between the views.
The example in Fig. 1.19 illustrates this problem. It is not very hard to convert between a behavioral description and the schematic description of an inverter, maintaining a correspondence between the components. However, the transistor descriptions have more components so there arises a complication in maintaining a correspondence: the problem of maintaining a many-to-one mapping of component functionality. The transistors, their power and ground connections, and all the internal wiring are equivalent to a single component in the schematic. A change to that schematic component must result in a change to all the corresponding transistor components. But what can be done when a change is made to a single transistor component? There may be no equivalent schematic for the resulting circuit.
Many CAD systems ignore the problem of view correspondence. Either they provide no conversion between views (because they work in only one) or they provide conversion but no maintenance or enforcement. Once the circuit has been translated to a different view, it is effectively a new circuit with no relationship to the former view. This is a problem for designers who wish to adjust their converted circuit, but need to ensure that the original specification is not being violated.
One solution to the problem of view correspondence is to convert all views to a common one, usually a low-level gate description, and compare the results. This has a number of problems, not least of which is the amount of time it takes to perform the conversion and comparison. Because of the time, this process must be done separately from the actual design and so is less convenient, since the interactive design process must be frequently paused and checked. Also, feedback of errors is difficult because of the same correspondence problem between the original views and the comparison view. Finally, this method of view association relies on the ability to convert views effectively. In some cases, there may be conversion problems that ruin everything.
Another solution to the problem of view correspondence is to maintain a mapping between the views and to complain about or prevent changes that violate the mapping. Unfortunately, this approach is too restrictive because designers will want to take advantage of the features of a given view by rearranging components. For example, the power and ground wires that are shared in the transistor view are not connected in schematics. Rearrangement of these connections may cause spurious correspondence errors from the design system.
No general solution to the problem of view correspondence has been found. However, if silicon compilation improves to the point at which designers no longer manipulate the low-level layout, then correspondence with that view will be unimportant. This is effectively the state of software compilation today, which functions well enough that most programmers do not need to examine the resulting machine code.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |
