 |
 |
|
|
The first aspect of VLSI design that must be represented is hierarchy. Hierarchical layouts have entire collections of circuit objects encapsulated in a cell definition. Instances of these cells then appear in other cells, which means that their entire contents exists at each appearance.
The representation of cell instances can be done with instance objects. These objects, which point to their cell definitions, are actually complex components, as opposed to primitive components such as the NAND gate. Complex components can use the same object structure as primitive components use, but their prototype objects have different attributes. For example, a primitive prototype may have attributes that describe it graphically, whereas a complex prototype will contain a list head that identifies the subobjects inside the cell. Although it is tempting to create a new object type so that design can be done with components and instances, the representation is much cleaner if only components are used because then there are fewer database objects and they can be treated uniformly.
 |
| FIGURE 3.8 Hierarchy: (a) Complex prototype for "Bignothing" (b) Primitive prototypes (c) Complex prototype for "Something" (d) Represented layout. |
Given this uniform representation of hierarchy, every cell is a component prototype. In Fig. 3.8, the design of Fig. 3.6 is shown in its proper perspective as a complex prototype called "Bignothing." Note that the "Out" connection on the rightmost inverter component in "Bignothing" is exported and called "Final." Other cells may contain instances of the "Bignothing" cell, thus including its contents. The "Something" cell in Fig. 3.8(c) has two components: one that is a primitive component and one that has a complex prototype. The complete layout is shown at the bottom of the figure.
| Because complex component prototypes are objects, the question of where to store their subobject list heads is resolved. These pointers are simply attributes in the complex-component prototype objects. However, a new issue is raised: how to represent the lists of component prototypes. To do this, two new object types must exist: the environment and the library. The environment is a collection of primitive-component prototypes, organized to form a design environment such as was discussed in Chapter 2. A library is a collection of complex component prototypes, or cells, presumably forming a consistent design. A good design system allows a number of different environments and permits multiple libraries to be manipulated. Figure 3.9 shows an overall view of the objects in such a design system. Environments provide the building blocks, which are composed into cells. Cells are then hierarchically placed in other cells, all of which are represented in libraries. A collection of library objects therefore contains everything of value in a particular design. |
|
Although libraries provide convenient ways to aggregate collections of cells, a further level of abstraction may be used to aggregate libraries by designer. In multiperson designs, a project can be defined to be a collection of works from many people [Clark and Zippel]. Subprojects identify the work of individuals and eventually arrive at libraries and cells to describe the actual design. Thus hierarchy can be used to describe both circuit organizations and human organizations.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |
