 |
© IEEE (1991). This is the author's version of the work. It is posted here by permission of IEEE for your personal use. Not for redistribution. The definitive version was published in IEEE Communications, Special Issue on Communications and VLSI, May 1991, pp56-62.
The current trend in CAD systems is to integrate the ever-growing number of synthesis and analysis tools. This paper argues that a much richer integration capability is necessary to accommodate not only these tools, but also multiple design environments, constraint systems, and even hardware platforms. In addition, the paper describes a specific integrating framework for synthesis and analysis tools that allows them to interact effectively. These integrating facilities have been implemented in the Electric VLSI Design System.
As circuits become larger, the demands on CAD systems increase greatly. Not only is there a need for increasingly larger design capacity, but systems must grow to accommodate many new synthesis and analysis tools. These tools proliferate because of new analysis techniques and more effective generation methods. The need to cut fabrication costs and quickly produce working parts demands new tools that can eliminate multiple design iterations. Also, the density and speed of modern ICs is so sensitive to layout features that effective tools must make use of both geometry and connectivity. Thus, many traditional tools are inadequate and must be rewritten.
Besides the need to handle many tools, CAD systems must now accommodate different environments of design. Not only should a system handle many integrated circuit technologies (MOS, Bipolar, Gallium Arsenide, etc.) but it must adapt readily to changing design-rules. Also, it is necessary to support higher-level design specifications such as schematics and hardware description languages such as VHDL.
Still another area of CAD system power is its user interface. Ideally, the interface should span all of the system's facilities so that a single set of commands is all that needs to be learned. The interface should also be customizable to meet group and individual needs. The ultimate interface should have an interpreted programming language available such as Lisp or Prolog.
To fully amplify the user's interactions, a CAD system can provide user-specified constraints. Examples of useful constraints include geometric rules and connectivity requirements. The ideal constraint solver applies these rules interactively during design.
The final important feature of a CAD system is platform independence. Given the proliferation of workstations, it is no longer reasonable to tie a system to one machine. Instead, the system must provide convenient hooks for portability so that it can run "on the engineer's desk," regardless of what is there.
This paper elaborates on the above requirements, showing how each can be met. A complete system, called Electric [1], exhibits all of these features, and its workings are described.
Early attempts at CAD tool integration simply merged two different packages. If a layout editor was able to interface to a simulator, it was considered integrated. Soon, these systems grew into monstrously complex sequences of programs for converting files, so that every facility could be incorporated. This technique defines the most basic form of integration: data file exchange. It is easy to add such integration to existing CAD systems, but effective feedback of errors or corrections is difficult to manage. In Ulysses, a complex "scripts language" manages the CAD tool interactions [2].
A more advanced form of data file integration is achieved when a single file type is mandated, for example the OCT system [3] or one that uses EDIF [4]. All tools then work from this single point, and the user interaction is vastly simplified. Of course, each tool must be rewritten to handle the new file type, and that format must be carefully chosen to handle all necessities. But the advantage is that a common set of I/O handlers can be used by each tool, making the programming task easier.
The tightest integration, used by many systems [5, 6, 7] including Electric, occurs when all of the common data is in memory. The tools then reside in a single program, or run in a multitasking environment linked by interprocess communication. This also requires tool recoding and careful database selection. But it makes tool writing the most simple since common facilities are available for database manipulation, I/O, user interface, and more. In fact, only the computational kernel of each tool needs to be written. In addition to tool simplification, placing all tools in memory allows them to interact with each other most effectively. Each tool can provide the others with relevant facilities, and customized usage policies can be implemented. This form of integration provides the greatest flexibility [8] and a hierarchy of tool functionality can be easily implemented [9]. The user's interactions are uniform and powerful.
Given that effective integration requires a common database, it is necessary to provide one with the most power. There must be no limitations on design size, and it should be easy to add additional information as required. This implies that an object-oriented database is best, one that allows an unlimited number of objects, and can add attributes to any object. This object/attribute model forms the basis of the database. In Electric, this model has a three-tiered structure layered on top that consists of design entities, circuitry, and design environments (see Figure 1).
|
The highest level of the database is design entities. Design entities are simply collections of circuitry that assemble to form the overall artifact. Traditionally, the design entity is called a "cell," and a single cell is edited at a time. However, Electric follows the OCT notion and calls each design entity a facet. Hierarchical use of facet instances within facet definitions provides the complexity of large circuits. Beyond basic hierarchy, it is useful to identify each facet as belonging to a different view, so that multiple styles of design can be done. View types include layout and schematics, contents and body, documentation, simulation stimuli, and more. Since designers often start by making abstract circuit specifications (schematics) and then do the actual layout, the availability of these different view types permits the CAD system to better track design progress.
Another necessary feature of facets is a version number. By recognizing a history of design activity, work can be partitioned among multiple designers, and design evolution can be tracked. Each facet also has creation and modification date information.
The final aspect of facets is the way in which they are aggregated. Libraries must exist to group the facets. In Electric, each library is a single disk file that may contain a collection of leaf facets, a complete hierarchy, or any other combination of facets.
The middle level of database organization is the circuitry. Schematic systems commonly represent circuitry as an abstract network of components and wires; while IC layout systems often represent circuitry as unconnected geometry on multiple layers. To be powerful and flexible, the database handles not only geometry and connectivity, but also behavior. Thus, the circuitry consists of connected components and wires, with placement, size, and arbitrary behavioral notations. Each facet contains multiple redundant circuitry information: a network, a geometric classifier (R-Trees [10]), and behavioral attributes such as directionality and delay.
The lowest level of the database is the design environment through which the circuitry is defined. Rather than store all information at the circuitry level, efficiency dictates that common attributes be described separately. Therefore, the shape, color, design-rules, connectivity rules, behavior, and other information are aggregated into design environments. Besides saving space, the placement of information in a design environment allows convenient defaults that can be overridden in the circuitry. For example, the simulation behavior of a transistor can be found in its design environment, or can be replaced individually if that transistor has specific behavior on it. Due to the uniformity of the database, it is even possible to place behavior on a facet, thus overriding the information on all of the circuitry inside it.
Electric allows multiple design environments and even allows free interaction of circuitry from different environments. For example, an IC layout can have dimensionless transistors from the schematic environment or even higher-level components from architectural environments. Although these abstract components cannot be fabricated, they can be simulated and subsequently replaced with true layout. This allows designs to be evolved from their initial abstract form towards final layout.
Electric's tool dispatcher is a powerful integrating facility. The dispatcher is an operating-system style kernel that distributes control to the tools and keeps them all current on changes made by the others. It works well for incremental and batch tools, synthesis and analysis tools, and even allows the user interface to act as a tool, thus unifying all nondatabase functions in the CAD system. The structure of the dispatcher could even handle multiprocessor distribution of tool activity.
The heart of the tool dispatcher is a round-robin manager that gives each tool a turn. Only tools that are currently on will get a turn. Therefore, batch tools such as PLA generators will be off and receive no turn. Also the user can disable incremental tools such as a design-rule checker by turning them off. When a tool is turned on, it is informed of all facets that have changed while it was off, thus allowing it to catch-up.
During a tool's turn, it may perform any task, preferably short. The design-rule checker uses its turn to examine all recently made changes. The compactor squeezes along a single axis. The user interface awaits a single command and executes it. This is the only time that changes may be made to the database.
A database change is either an object creation/deletion or an attribute creation/deletion/modification. In addition, groups of changes to an object are bracketed with start/end announcements so that multiple changes to an object can be coordinated properly. All changes are made through a procedural interface to keep track of the activity and to prevent undebugged tools from doing damage. Table I shows examples of changes.
| Operation | Steps |
|---|---|
| Create a transistor | Create transistor object End change to transistor object |
| Delete a wire | Start change to wire object Delete wire object |
| Change size of a contact | Start change to contact object Modify size attributes on contact object End change to contact object |
When a tool's turn is over, the database broadcasts all changes made by that tool. This broadcast is made to all tools that are on. Many tools are not interested in database change, so they can ignore the information. For some, however, it is very useful. The design-rule checker queues all changes so that it can check (and possibly react) during its turn. The user interface updates the display when it receives a broadcast. This allows it to keep the display current, regardless of the source of the change.
The turn/broadcast formalism has the drawback that incremental tools must divide their activities into two phases. However, this is typically a natural division, so it does not cause much difficulty. Besides, the advantages of this tool integrating policy far outweigh the difficulty. First of all, each tool can interact cleanly with the others. Second, by passing all changes through a single channel, change control is easily managed. Finally, it is possible to build constraint systems into the path, allowing powerful database manipulation. Figure 2 illustrates the entire process.
 |
In Electric, constraint systems are the first to receive the changes made by a tool. Each change type (create/delete object, create/delete/modify attribute) is passed through the constraint system, which may then generate other changes. At the end of a tool's turn, the constraint solver has a final opportunity to react to the changes, optionally delaying solving until this point. New constraint systems are easy to install because they are merely a set of filter routines for each type of change.
After the changes have passed through the constraint system, they are recorded by the change control system and then broadcast to the tools. Since the change control system records constrained changes from all tools, it is easily able to undo any command, even if it has been acted upon by many other tools. Undo simply consists of a broadcast in reverse: creations become deletions, deletions become creations, start-change announcements become end-change announcements, etc. Electric's change control system can record arbitrary amounts of change, thus allowing many previous commands to be undone.
Besides allowing multiple database changes to be undone, Electric allows all user commands to be undone. This is because all commands, even simple state changes, are implemented as database change. For example, when a component is selected, the "selection" attribute on the user-interface object is modified. Thus, an undo will actually reset that attribute and restore the component selection to the previous piece of circuitry.
The inclusion of the user interface in the list of active tools means that the user will always be at one specific point in the dispatching sequence. After entering a command, the remaining tools will always operate in a fixed order. Therefore, tool ordering is important: synthesis tools should follow the user interface and precede the analysis tools. This allows all generative actions such as compaction and routing to occur before final analysis such as design and electrical rules checking.
Electric's tool dispatching scheme works well for incremental tools. Batch tools such as generators fit in this scheme by being off. When turned on, they do their complete function and then turn themselves off again. Thus, Electric provides a general-purpose framework for all CAD tools.
To illustrate the power of Electric's tool control, two examples will be given. The first example describes interaction with an incremental router that watches design activity and adds connecting wires where appropriate. The second example describes interaction with a background simulation activity (SPICE).
Electric has a router called the "mimic-router" which, when activated, amplifies the user's wiring actions by duplicating them at other similar places in the circuit. This is particularly useful in array-based design, where the user need only wire a single element in the array and the router will do the rest. This tool is enabled by turning it on. It then receives broadcasts of all changes made to the database.
The mimic-router looks for database changes that add wires. These changes must originate from the user-interface (it is not reasonable to mimic wiring from other tools such as PLA generators, since they usually do their own wiring). Also, the wiring changes must not be part of a more complex operation, such as duplication of a collection of circuitry.
During the user interface tool's turn, user commands can be executed. If the user makes an appropriate wire addition, the mimic-router will notice and queue the addition until its turn.
During the mimic-router's turn, the tool looks at each wire addition and searches for similar situations elsewhere in the facet. A similar situation is defined as having endpoints of the same type spaced by the same distance, and not already connected. The mimic router then adds the wires.
When the mimic-router is finished with its turn, the changes are broadcast to all tools. This causes the user interface to display the added wires. To the user, a simple addition of a wire has resulted in many others appearing on the display.
SPICE simulation is a much different tool. The simulator runs in a separate process and does not interact with the user. In fact, all input stimulus and output plot requests must be coded in advance, along with the structural information.
To run SPICE, the user provides a graphical description of the input and output requirements by using Source and Meter components from the schematic technology (see Figure 3). The user then turns the SPICE simulation tool on.
 |
When it is the SPICE simulation tool's turn, it first writes the current facet in the appropriate format for the SPICE simulator. Then, it invokes the simulator as a subprocess and waits for it to finish. Next, it reads the output listing of the simulator and creates a plot on the display (see Figure 4). Finally, the tool turns itself off. Thus, it runs as a single activity, all during its turn.
 |
If the execution of the simulator is too time consuming, the tool can be requested to prepare input but not run the simulator. The user can then run the simulation manually, and the tool can be told to read the output listing at a later time.
One interesting aspect of the SPICE plot is that it is actually a new facet with the "simulation-output" view. It is constructed from special graphical components, and becomes a permanent part of the database. The user can make hardcopy, zoom into particular areas, and even modify the data!
An important aspect of CAD system flexibility, which is overlooked by many programs, is machine independence. Most systems are integrally tied to a single computer and display. The argument for such entanglement is that the greatest efficiency and speed can be achieved through dedicated programming. However, Electric's graphics framework is both general-purpose and efficient.
All user interactions in Electric are channeled through a single module that can easily be replaced when porting to a new machine. This module handles graphic display, pointer-device input (mouse or tablet), and keyboard input. Keyboard input is handled here because it is often tied to pointer input in the operating system.
Graphic display is the heart of the module. The interface provides for drawing lines, boxes, polygons, circles, and text. Special block transfer routines handle area movement, inverting, save and restore. Other special routines exist specifically for CAD graphics (grid display, cursor shape). Each drawing routine is provided with texture and color information, which includes multiple options for different display types (color vs. black&white).
Since not all displays can provide all of the I/O options that the graphic interface defines, there is one additional routine which reports the actual features that are handled. Electric then "works around the missing features, for example redrawing if block transfer doesn't exist. Some missing features cause commands to disappear. Nevertheless, the system can run in some capacity on virtually any machine.
The Electric VLSI Design System has been in use since 1983. Initially offered only to Universities, it is now also a commercial system. Because of its source-code distribution, the associated textbook on CAD systems [11], and copious internals documentation, Electric provides a complete curriculum in CAD system study. The program is written in C and can support interfaces to popular Lisp and Prolog interpreters.
Electric's tool suite includes many synthesis and analysis functions. There is an incremental design-rule checker as well as an interface to the Dracula system. There are eleven simulator interfaces (SPICE, Verilog, Silos, Cadat, Tegas, and many university tools), network consistency checking, a compactor, three routers, two PLA generators, and a VHDL-driven place-and-route system.
The design environments in Electric include two nMOS design-rules, six CMOS design-rules (including MOSIS), Bipolar, Gallium Arsenide, schematics, digital filter, and even an artwork environment for figure layout and general embellishment. Besides the environments provided, an editing facility exists for modifying or creating new ones.
Electric has two layout constraint systems. The standard one allows wires to be kept at a constant angle and/or length. This propagates through circuitry, even crossing hierarchical levels, to keep the layout connected. The alternate constraint system uses linear inequalities on wire lengths [12, 13, 14].
Electric runs on many hardware platforms including those from DEC, SUN, Apollo, HP, Apple, and more. It has specific drivers for these machines, as well as an X Window System interface for general display control. The system thus exhibits all of the forms of integration described in this paper.
CAD systems are becoming increasingly complex to meet the demands of circuit designers. To provide for whatever the future may bring, these systems must be extendible in a number of different directions. Besides accommodating new synthesis and analysis tools, integration capabilities must be able to handle evolving design environments, powerful constraint systems, and even new hardware platforms. The Electric VLSI Design System provides all of this flexibility. The system also has a novel tool integration scheme that allows multiple tools to interact powerfully.
Steven M. Rubin holds a M.S. and a Ph.D. in computer science from Carnegie Mellon University. He is a computer scientist in the Advanced Technology Group at Apple Computer, and is also the Vice President of Electric Editor Incorporated. His primary interest is Computer-Aided Design (CAD), both two-dimensional circuit layout and three dimensional architectural drawing. Mr. Rubin has also worked at Schlumberger, Fairchild, and Bell Labs. He is the author of Computer Aids for VLSI Design, a textbook for students of circuit CAD systems.