 |
 |
|
|
The next aspect of VLSI design that must be represented is views and their relationships. Representation of views makes use of different methods for each view. Layout views require geometric representations and schematic views require topological representations, both of which are discussed in the following sections. Temporal views make use of relative event times and signal values [Arnold; Borriello]. All of these views should be able to link together to create a single object [Zippel; Clark and Zippel]. A good view-correspondence system allows these view links to be established uniformly and thoroughly in the database.
There are no truly good view-correspondence systems today, so their representational needs are ill-defined. What is known is that arbitrary information must be available to do proper correspondence maintenance. Combined with the other representational facilities described in this chapter, a few additional attribute types should fill the need. In particular, the database must be able to link two designs done in different views and to describe their relationship fully.
Linking of cells is done with pointer attributes that can relate the various objects in the database. For example, two cells that represent the same circuit in different views will each have attributes that identify the cell in the other view. Components and wires inside the cells will have attributes that link them to their counterparts in the other view. This pointer information links the database across hierarchies, showing the same design in different layout styles. If the views are so different as to be unable to associate common cells, then further pointer information must be represented. For example, the link between an algorithm and a layout will have to identify textual equations and their equivalent components. Thus the capability demanded by views is the ability for attributes to contain pointers to any other object in the database.
Besides storing pointers, it is useful to have classes of pointers that carry meaning. One database system for CAD has three different pointer types that can describe a rich set of relationships [Atwood]. The a-part-of pointer is for composition ("contact 7 is a-part-of the Inverter cell"). The an-instance-of pointer is for type qualification ("component 12 is an-instance-of an Inverter cell"). Finally, the a-kind-of pointer describes relationships between categories ("Superbuffer is a-kind-of Inverter"). By allowing multiple a-kind-of links and selecting common attributes among the linked objects, the database can store a complex yet compact description. For example, Superbuffer is a-kind-of MOS cell, but it is also a-kind-of Inverter and a-kind-of Driver. The primary a-kind-of link is to MOS cell, with weaker links to Inverter and Driver, selecting only those properties that are relevant.
| The most important feature of view correspondence is its many-to-one mapping of components. A single object may have a pointer to multiple other objects (see Fig. 3.10). Simple pointer attributes will not be sufficient for this, so an array construct will be needed to provide one attribute with many pointers. Arrays should have the capability of being either fixed length, with the length stored in the attribute, or variable length, being delimited by a null termination pointer much like that in a linked list. One-dimensional attribute arrays are sufficient because more complex data structures can all be stored as vectors. |
|
The aspect of design that makes view correspondence hard to maintain is the fact that designers are constantly rearranging the objects that are linked between views. When this is done, some of the links are temporarily broken. The attributes must be able to track this information so that the design can be checked and reconstructed. Therefore every view link needs additional information for state (the pointer is valid/invalid, the designer is aware/unaware of the change, the data of the change is ---, and so on), and even a textual field in which notes and comments are made about the view. A proper software approach to this problem would use structured records as attributes so that the varying kinds of information could be kept in one place. Even without this structuring of attributes, it is necessary to have all these data types. A text-message attribute is useful for design documentation, and integer arrays can hold arbitrary information such as design parameter and status tables. All of this is useful in the representation of views.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |
