 |
 |
|
|
It is not enough for a CAD system to provide a full spectrum of design environments; there must also be a set of tools for working in these environments to manipulate the circuitry. These synthesis and analysis tools must be available in an easy-to-use way, with common interfaces for both humans and machines. To achieve this integration, Electric has provided a standard structure of subroutine calls that each tool provides and invokes.
The tool interface in Electric resembles a miniature operating system with round-robin control. Electric continuously cycles through each tool, calling its turn routine, which gives it a chance to do some processing. Some tools may be switched off, in which case they do not function incrementally and do not receive a turn. During a tool's turn, it may examine the database and change it; the former being done by subroutine calls or direct data structure access and the latter being done exclusively by subroutine calls. Electric accumulates changes made during a tool's turn and broadcasts them to all tools when the turn is over. A broadcast consists of a set of subroutine calls to report new, deleted, and modified nodes, arcs, ports, and cells. Because of the constraint systems in the database, the actual changes may be more extensive than the requested changes, so the complete set is broadcast to every tool, including the one that issued the original changes. During the broadcast, a tool may take local action but it may not issue additional changes; these must be delayed until its turn.
The turn-broadcast cycle of tool invocation allows powerful control of design activity in a highly modular environment. An indication of the modularity is the fact that the entire user interface acts as a tool and works within this framework rather than being part of the database. Thus it is no different from any other tool and can interact uniformly with all of them.
Not only does the database manage the broadcast of changes, but it also handles the changes' undoing. All changes made by a tool during its turn are collected in a batch that is retained so that it can be reversed if undo is requested. The number of retained batches is usually more than the number of tools, so that a complete action and all reactions can be undone. The undo mechanism simply reverses the sense of every change and broadcasts it to each tool.
| An example of tool interaction will illustrate the flexibility of this scheme. Assume that there are four tools: the user interface, the router, the design-rule checker, and the simulator (see Fig. 11.10). All but the last are on, and it is currently the user interface's turn (action 1 in the figure). During its turn, the user interface waits for a single command and executes it; in this case a component is created. The user interface merely sends this change to the database (action 2) and then returns control to Electric-its turn is over. This new component is then broadcast to the three "on" tools (action 3) so they can display it (the user interface), and queue it for further analysis (router and design-rule checker). |
|
When the router gets a turn (action 4) it examines its queue of newly created or manipulated objects and checks to see whether it needs to make any connections. Routing action is not always incremental, but can be in Electric and is in this example. Any changes made (action 5) are again broadcast (action 6) and handled appropriately by each tool. For example, the user interface shows the new wires. The router knows not to examine its own changes when they are broadcast.
The final tool to run in this example is the design-rule checker (action 7), which looks for layout errors in the objects that have changed. All changes made by previous tools are checked here and any error messages are printed. Note that a correcting design-rule checker would be perfectly feasible to implement in this system but the current tool makes no changes. The simulator tool, being off, is skipped and control returns to the user interface.
The simulator tool can be made to run simply by turning it on. Once on, it will receive a turn immediately (since the command to start simulation completes the user interface's turn, and the absence of change causes control to roll to the simulator quickly). During its turn, the simulator will produce a netlist and/or run, depending on the particular simulation being done. The final activity of the simulator is to turn itself off since it has performed a one-shot activity. Thus even batch tools can function within the Electric control scheme.
Although this example describes the overall nature of some tools in Electric, there is much more to say about them. The rest of this section discusses the salient features of the individual tools of the Electric VLSI design system.
The user interface is the most intelligent of Electric's tools; it is able to do both synthesis and analysis. During its turn, it waits for a single command from the keyboard or the pointing device and performs that activity. Commands can be issued as single keystrokes, button pushes on the pointing device, menu selections (fixed, pulldown, or pop-up), or full commands typed in with their parameters. The first three forms are shorthand for the last form, and dynamic binding can attach any full command to a single key, button, or menu. Combined with a parameterized macro facility, variables, and conditionals, the user interface can be tailored to resemble any system that is familiar to or comfortable for the user.
There are a number of different kinds of commands that can be issued to the user interface. Change commands such as "move," "create," and "undo" result in the change being sent to the database for constraint analysis and subsequent display when broadcast back. Nonchange commands, such as the selection of a current object or a request to display a grid, affect the user interface and the screen without altering the database. The user interface relinquishes control and ends its turn even when nonchange commands are issued.
Another class of commands is one that affects other tools. The user interface can turn on or off any tool (except itself), thus controlling the entire system. When an incremental tool such as the design-rule checker is turned off, that tool will no longer examine each change. However, the database tracks which cells have been changed while a tool is off, and the tool will be able to catch up when turned back on, thus acting in a batch mode.
Many commands that appear to be standard functions of a design system are actually implemented as invocations to other tools. For example, reading and writing libraries is done by directing the I/O tool, and network highlighting is done through a request to the network-maintenance tool.
In addition to being very flexible and powerful, the user interface is coded in a highly modular style that permits ease of porting to any graphic display. All graphics input and output is done through a device-independent subroutine package that currently supports UNIX, Windows, and Macintosh workstations.
The reading and writing of the database in various formats is the job of the input/output tool. Currently this system can handle two Electric-specific formats, one binary and one text. The binary file format is more compact but less portable to machines with different bit organization. In addition, the I/O system can read and write CIF [Hon and Sequin], GDS II [Calma], EDIF [EDIF committee], and many other formats. Unfortunately, CIF and GDS II input appears as a collection of pure-layer components that are totally unconnected. A final format that the I/O system handles is plot output in PostScript, HPGL, or QuickDraw.
The Electric design-rule checker runs incrementally, checking each change as it is made to the circuit. It operates by comparing the boundaries of all polygons on new and changed components. Although this polygonal comparison is less efficient than are raster methods when examining entire circuits, it is more efficient when checking small numbers of changes. To make the tool even smarter, each polygon is tied to a particular network path so that appropriate rules can be used when components are actually connected. The use of connectivity makes the design-rule checker more accurate and less prone to finding spurious errors. The only drawback of the current design-rule checker is that it is not hierarchical because incremental checking of all subcells would take too much time.
Another facility of the design-rule tool is a global short-circuit detector, which finds geometric connections that are not specified in the network. This is done by flattening the hierarchy and associating each polygon with a network node number. The list is then sorted to find polygon overlaps on different nets. In addition to finding short-circuits, this also helps to verify Electric's network information by finding components that should be, and even appear to be, connected, but simply are not.
Electric currently has many simulator interfaces that generate netlists for various simulators. ESIM, RSIM, and RNL [Baker and Terman] simulate MOS at a switch level as does MOSSIM [Bryant]. CADAT [HHB] is a functional simulator and MARS [Singh] is an experimental hierarchical simulator that can handle arbitrary behavioral specification.
Besides simulator interfaces, Electric has a gate-level simulator built-in. This 12-state simulator (based on work at Queen's University [Serbin]) can accept input values and display simulation results in a separate waveform window or on the actual circuit.
| It is interesting to examine the SPICE [Nagel] simulation environment in Electric, which can graphically specify all parameters. Connecting meter and source components to a circuit, and parameterizing them appropriately, allows a complete input and output to be determined (see Fig. 11.11). When the simulation runs, the output values are used to generate a waveform plot with artwork primitives. Since this plot is a cell like any other, it can be saved as documentation, zoomed into for closer examination, and even altered with the normal editing commands to fudge the data! |
|
The routers in Electric can handle many functions. A maze router is available to make point-to-point connections and a river router connects multiple sets of points on opposite sides of a rectangular area.
When array-based layout is being done, implicit connections exist where two cells abut. These connections must be explicit for Electric to maintain its topological view of the circuit. To help do this, two stitching functions exist for the explicit connection of implicitly joined circuitry. The auto-stitcher looks for connection sites that adjoin or overlap geometrically and connects them explicitly. The mimic-stitcher watches user activity as wires are placed, and creates other wires in similar situations throughout the layout. These two stitchers work incrementally, adding wires as they are needed.
Electric has a one-dimensional compacter that can work in a batch style or can function incrementally. When turned on, it adjusts the layout to its minimal design-rule separation. If the compacter remains on, it will close up the circuit when objects are deleted and will spread open the layout to make room for new components.
There are two Programmable-Logic-Array generators in Electric: one specifically tailored for nMOS layout and another that is a general-purpose tiling engine. Both work from personality tables that describe an array of elements. The nMOS PLA generator produces all the surrounding circuitry, including drivers and power connections, so that a complete functioning module is available. The general-purpose PLA generator produces only those arrays of logic without any interconnect. However, it works from a user-specified library of array elements and orientation examples, so this library can include any peripheral circuitry.
The QUISC silicon compiler accepts a structural VHDL description of a circuit and a standard cell library. It compiles the VHDL to a netlist, places the standard cells, and routes them to create layout for the VHDL [Kostiuk].
The VHDL compiler is particularly interesting because it is able to produce a number of different netlist formats, and it can therefore drive the simulator as well as the silicon compiler. Also, the VHDL compiler can function in reverse, generating VHDL from a schematic. Therefore, users who wish to simulate or build layout from a schematic can do so easily.
The compensation system adjusts geometry to account for process-specific manufacturing effects. It can understand actual process features (such as laser writer parameters) and adjusts geometry properly, regardless of the direction of compensation. The system even understands interior versus exterior geometry and knows to move edges differently if they are defining a hole.
There is a network-maintainer tool that merely propagates node information throughout the circuit whenever a change is made. It keeps lists of net names and can highlight any connected path.
Many other tools could fit easily in Electric: Analysis tools such as power estimation, timing verification, and test-vector generation would all be useful. More synthesis tools such as floor-planners and better routers will someday be added. Not only is the list of different tools unbounded, but the number of tools in a given class can grow to accommodate experimental versions of any CAD algorithm. Electric's integration scheme is designed to be able to incorporate modularly any VLSI CAD tool.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |
