OpenAccess can represent data from structural RTL through GDS II mask-level constructs. It supports automated and custom forms of design data. OpenAccess supports analog and mixed-signal design data constructs and includes full support for pure-digital designs. In the layout domain, OpenAccess supports full chip-level (with I/O pads, blocks and top-level routing), block-level (for synthesized or custom-generated blocks), and cell-level (for cell libraries) design representations.

OpenAccess is a fully hierarchical database. The distinctions between logical and physical domains are understood and supported by OpenAccess. OpenAccess is well suited for both interactive and batch applications, and large suites of applications can make efficient use of the database to develop interdependent incremental applications.

This paper introduces, in stages, the data model supported in OpenAccess. With the core schema, we start from the simplest forms of layout, move through a discussion of connectivity (identical for netlist, layout, or schematic data), and conclude with a discussion of representations of design hierarchy. We describe advanced parts of the schema, such as the parasitic representation including coupling, signal integrity, and place-and-route constructs.

We describe the technology database, an adjunct to the design databases of OpenAccess, and show how it is cross-linked to the design data. We introduce the extensibility mechanisms of the database and show how they can be used to most efficiently layer applications on top of OpenAccess. In conclusion, we list future areas of work that are under consideration by the OpenAccess Change Team, the democratic body that controls the evolution of OpenAccess going forward.

Unified data model
When constructing a SoC implementation system, one of the major problems is the number of data translations required. In Figure 1, each red box represents a translator. The problems that occur in this all-too-typical implementation flow include: problems identifying master data; performance problems due to the number and frequency of translations required; and different semantic interpretations of the different tools showing through the various translations as flow problems.

Figure 1 - Translation-based design flow

Figure 2 demonstrates the advantages of using a unified data model. The semantic interpretation is more likely to be correct, although any application can cause problems if it isn't careful. There is a single place to store the master data. Fewer translations are required, only being necessary when one must interface to the inevitable tool that doesn't yet use the standard.

Figure 2 - Unified data model

Looking beyond Figure 2 reveals a model in which cooperating applications use the data model as an in-memory model, and the real power of a unified data model comes about. This is the ultimate vision for OpenAccess. It will take several years to realize this vision, but it is the motivating force behind the standard.

In order to better understand the details of OpenAccess, this paper presents the OpenAccess version 2 data model. We avoid programming and API-level details, leaving that for another paper. By concentrating on the semantic details of the data model, we hope that the reader will see the similarities in concepts to their own data models, and that this will create interest in looking more deeply into the OpenAccess standard.

Shapes
The data models in OpenAccess have evolved over the years from a combined netlist/layout database. At the core are the many layout shapes that can be represented. The simplest shape is a dot, which represents a single point in space. Having no width, it is never used as an actual mask shape, but finds use, for example, in layout and schematic diagrams to represent the center of a pin. Note that a dot may have a width and/or height) The display of dots is left to the application rendering the data, and these dots are usually depicted as a diamond or cross.

The most basic mask shape is a rectangle, which is specified by its lower-left and upper-right points. Rectangles are used in low-level, full-custom layout, and are Manhattan by definition. They are sometimes used in automated layout in the construction of power stripes and rings.

Polygons represent the next level of complexity above rectangles. They may be Manhattan, have Manhattan and 45-degree edges, or represent all-angle geometries. All polygons represent real-mask data and are hence closed (the last point in the polygon has an implicit connection to the first point). In full-custom layout, and in cell design, polygons are used quite often. In automated layout, polygons are often used to represent blockages in cell abstractions. Note that you can represent a rotated (non-orthogonal) rectangle as a polygon.

Wiring is often represented using lines and paths. These are objects that are specified by their centerline, and in the case of a path, an associated width. They can contain multiple segments, going from point to point to point. Lines have no width, and are an object separate from paths, so their drawn width can be controlled by the rendering application. Lines are similar to a polygon that is open -- point lists define them both. Both lines and paths can have segments that are Manhattan, 45 degrees, or all-angles. Computation of the boundary of a path is taken care of by the database to ensure consistent representation of paths. This is only a problem or issue for the exterior points in an acute all-angle path.

Two forms of text can be added to layout, the text and textDisplay. It is useful to note that both of these objects are never made mask data (similar to a dot), and provide useful annotations to the layout or schematic diagram. Text that must appear on the mask must be generated using some mixture of rectangles and polygons. The text object is a simple annotation that has a location, a font, and a string. A textDisplay is a text object that is associated with an owning object. For example, you can attach a textDisplay to a rectangle representing a pin that has the text of the pin's name. In this way, as the pin rectangle is moved, the textDisplay moves with it.

There are three more basic shapes -- the ellipse, donut, and arc. Ellipses have their coordinate axes consistent with the X- and Y-axes, so it isn't possible to represent a rotated ellipse. A circle is a subset of an ellipse and is represented using the ellipse object. Donuts can be viewed as a circle that has a width.

An arc is essentially a segment of an ellipse. It is specified by and ellipse and start and end angles, and is almost exclusively used for the construction of schematic gate symbols. In layout design, the ellipses and donuts are often used in bipolar or microwave layouts, or in specialty designs such as radiation-hard or high-voltage IC designs. Most often these three constructs are used to construct schematic diagrams.

Layers and purposes
All shapes have an associated layer and purpose. The layer translates to a mask layer, although the drawn layers contained in the database are often modified before actual masks are created. Example layers might be Metal1, M3, and M1Oxide. Their names are defined in the technology database described below.

A number that is currently an unsigned integer defines layers, and the purpose is a user-definable specification. It is often used to distinguish shapes by their use. For example, a design group might want to distinguish power, ground, clock, and signal lines and have them drawn in different colors or stipple patterns. Giving each layer four different purposes allows for this.

Another group might want to distinguish shapes that are associated with nets or distinguish pins from shapes that are not pins. Having pin, net, and drawing purposes for each layer allows for this. Yet another group might have everything drawn the same way for a given layer. Using the predefined purpose drawing accomplishes this -- essentially ignoring purposes.

Inside the database, the layer-purpose pair - the combination of layer and purpose as a single object - organizes shapes. This allows applications to traverse the shape data by layer and purpose taken together, by layer alone, or all shapes in a given cell. Again, since purposes are user-defined, the control of its use is entirely up to the applications and the end users.

In rendering applications, each layer-purpose pair will often be drawn using a unique color and stipple pattern, or color blend. The design and technology databases contain no direct information about this color mapping. This is left to the application programs.

Routes and vias
One of the objects that give OpenAccess its very high capacity is the route, depicted in Figure 3. A route is similar to a path in that it goes from point to point to point. However, a route may change layers, and possibly widths, so it is a figure that can have components on many different layers.

Figure 3 - Route

Vias are embedded within routes where layer changes occur. The vias may be simple or complex, and examples are shown in Figures 4 and 5. Another distinguishing characteristic of a route is that it has explicit physical connections at its endpoints. This is extremely useful in layout and allows applications to efficiently trace physical connections from one place to another.

Figure 4 - A simple via

Figure 5 - A complex via

Routes are encoded as a list of elements, where each element can be a segment on a given layer or a via. Since vias can be viewed as segments in the Z plane, each route element represents a point-to-point connection in three-space. Each segment has its own layer (and purpose) and width. Similar to paths, the boundaries for routes are calculated by the database to ensure a consistent interpretation.

Instances and layout hierarchy
Once a cell is designed, it is good to be able to reuse the design, for many reasons. If you need to fix the cell, you can fix it in one place and have the fix reflected everywhere the cell is used. With large designs, it is almost a requirement to be able to partition the design into subtasks that can be developed in parallel by independent design teams. Reusing cell data can also increase the capacity of a design system, as one only needs to store the data once before it can be used several times. Design reuse is depicted in Figure 6.

Figure 6 - Design reuse

For these reasons, OpenAccess is a hierarchical database. Each cell becomes a master, and in a higher-level design it can be placed as an instance and reused. Changes to the master will be reflected in each instance. Hierarchies must form a tree, not a graph, so that no lower-level master can create instances of masters above it in the design tree.

The form of the hierarchy created in OpenAccess is called a folded hierarchy, shown in Figure 7. This is distinguished from an unfolded hierarchy (in Figure 8), in which a copy of the master is made for each instance within the design.

Figure 7 - A folded hierarchy

Figure 8 - An unfolded hierarchy

Each cell has its own coordinate system and origin. When instances are created, they have an origin and orientation. The origin defines the point in the cell where the origin (0,0 point) of the instance's master is placed. The orientation defines the cell's rotation and/or mirroring about this origin point. Another way of looking at this is that the orientation happens first, and then the resulting view is translated to the origin point for placement.

OpenAccess supports both simple instances and arrayed instances. An arrayed instance specifies the master to be referenced and the number of rows and columns in the array. Arrayed instances are commonly used in layout for memory cores and other replicated structures.

Connectivity
The OpenAccess database is fully capable of representing hierarchical netlist information and relating the netlist information to the physical layout. The net is the basic connectivity construct. It describes a net or signal of hierarchy. Shapes and routes may be associated with nets, and it is possible to iterate through shapes associated with a net. The database stores connectivity information, but it does not directly determine the connectivity.

Thus, it would be possible (although erroneous) for an application to create two intersecting paths on the same layer but place them in different nets. This would not be discovered by the database, though it would be found through a verification application.

This notion of deferred consistency is found throughout the OpenAccess database. It exists in order to make interactive operations possible. In the previous example, it would be very difficult for an application to move the paths from one net to another if the database enforced semantic correctness at all times. By ensuring syntactic correctness but leaving semantic correctness to the application layers, the database is more efficient and allows for evolution of applications in a freer way.

Multi-bit connectivity is supported, and it is used in netlist- and schematic-level cells. Layouts rarely have need for bus information, except as grouping mechanisms for single-bit nets. A bus is an aggregation of nets into a single object that shares a common base name and has each bit within the bus identified by its index in the bus. A bundle is an aggregation of otherwise unrelated nets into a single entity. Buses may currently contain only single-bit nets. Bundles may contain single-bit nets or buses as components, but not other bundles (that is, bundles may not be hierarchical.)

Connectivity and hierarchy
Whenever a net is visible from outside a given cell, a terminal (term) is created. A term is really just an exported net. For historical reasons, the terminal name may be different from its associated net, although by convention it is most often the same. Because of multi-bit connectivity, you can create busTerms and bundleTerms to match the exported bus and bundle nets.

Due to the optimizations found throughout the synthesis world, OpenAccess supports shorted terminals. This means that a given net may have multiple terminals, each of which is equivalent and represents the same connection outside the cell. In such a case, one of the terminals is the preferred one and the rest form aliases for the preferred terminal.

When an instance of a cell is placed and the cell contains connectivity, InstTerm objects are used to link the connectivity across hierarchy boundaries. The InstTerm provides a connection between a net at the current level and the terminal within the instantiated cell. If you think of a cell's master as plugging into the instance "socket," the InstTerms are the pins of the socket. Even though InstTerms connect multi-bit nets and terms, they themselves contain no explicit information about the width of the connection. Thus, we have no need for busInstTerms or bundleInstTerms. The only requirement is that the width of the net match the width of the terminal to which it is connected.

Name mapping
One of the most challenging aspects of building robust EDA flows involves making sure the names that are supplied meet the requirements of the tools in the flow, and match at points where data that has been manipulated by different applications come back together. Since a single-vendor flow is almost unheard of - and since each different EDA application has different interpretations of allowed names - this can become a huge problem.

OpenAccess has a simple approach to this name-mapping problem. For any string that can or should be mapped, OpenAccess has a Name object. Since these objects are used directly within the database for purposes such as comparison and lookup, the database operations (and the operations within applications using the database) are as efficient as possible. It only becomes necessary to map names when going into or coming out of the database. This is where the NameSpace object comes into play.

The NameSpace object can be declared in variations that describe the Verilog, LEF/DEF, VHDL, CDBA, FileSystem, and Genesis-internal namespaces. This subsystem implements algorithmically invertible name conversion that can handle keywords (Verilog, VHDL), case insensitivity (VHDL, Windows FileSystem), and differing bus and hierarchy delimiters.

Implementing translation layers becomes very easy using these objects. Take Verilog as an example. For a Verilog input translator, one just takes the raw Verilog names (including escaping where used) and converts the string into an OpenAccess Name using a Verilog NameSpace object. This Name is then used to create the objects associated with the name. Once inside the database, it could be retrieved in a different namespace (say, LEF/DEF). Since these conversions are algorithmically invertible, as long as the conversions are used throughout a flow, virtually all name-mapping issues disappear.

Storage of OpenAccess data
The basic unit of design data in the OpenAccess database is the Cellview. When you open a design file, this is the object that is returned. It is used as a starting point to traverse the data in the file or as the basic object when creating new data inside the cellview.

Cellviews are organized into libraries, and full specification of a Cellview is given by the triple of Lib, Cell, and View. The Cell typically is the equivalent of the Verilog module name. The View name is used within the Cell to link together related views of the same Cell. Use of the View name is entirely up to the end user. Applications should not make any assumptions about View names, although in practice some conventions tend to creep into common usage (such as layout for mask layout, schematic for schematic drawings).

Libraries and file system mapping
In the Lib/Cell/View structure, the mapping into the file system is simple. First, a file named cds.lib, which can be located in the current directory in which an application is started or in the user's home directory, is consulted. This file provides a simple binding between the symbolic Lib name and the directory on disk that contains the library.

By convention, the Lib name and the tail component of the directory path are the same, but this is not required. Each Lib directory contains directories of Cells. The Cells are also directories and contain directories of Views. Each View directory contains the database file. It may also contain other files, and if multiple source data files are contained in the View directory, a file named "master.tag" is present to indicate which of the source data files is the master.

In this way, other design data, in addition to the OpenAccess DB data, may be kept in the library. The OpenAccess APIs contain methods that can be used to place and later locate these other files that are associated with OpenAccess cellviews but which are not OpenAccess design data. An example of this usage that occurs in a current Cadence tool is in the NC-Sim mixed-language simulator product, which keeps source Verilog files along with the OpenAccess data that represents a given module.

End users use two major systems for organizing View names. The first uses View names to represent the different kinds of information available in the differing views. Names like netlist, layout, schematic, and timingModel are representative of this usage. The second system uses the View names to represent flow progression as a design evolves. Names like placed, globalRouted, clockTree, routed, and extracted are representative of this usage. Remember that the View names are entirely up to the end user and that applications should not hardcode any convention regarding view names.

Placement and routing models
A cluster is a way of aggregating a group of instances for partitioning and/or placement purposes without creating a real level of hierarchy. Clusters can be physical and have an associated rectangle defining their allowed/placed area, or clusters may be logical, prompting a placer to closely place the instances while not specifying a fixed area. The physical clusters can be porous, meaning that other cells not in a given cluster may be placed within the region rectangle, or they may be solid, implying that other cells may not be placed inside the cluster. Clusters can be hierarchical, containing other clusters.

It is a simple operation to take a cluster and turn it into a Cellview (and conversely to turn a Cellview into a cluster). These operations are used heavily in floorplanning and generally in place-and-route.

Scan Chains are used to link together the scan registers used in a design that allow testing of the design after fabrication. The OpenAccess ScanChain objects allow labeling of the scan nets and components, and let the designer determine how much flexibility the place-and-route applications have to reorder the scan nets. At the two extremes, the scan nets can be identified without any constraint - this lets the place-and-route programs freely ignore the scan nets during placement and freely reorganize them during routing to minimize the scan-related routes.

At the other extreme, the entire scan order may be identified as fixed - this lets the place-and-route programs know that they should take the scan nets into consideration during place-and-route. Typical usage lies somewhere between the two extremes, and has lower-level blocks or regions with fixed scan subsets which may be reorganized along with the scan registers at the current top level of the design.

Sites define allowed placement locations for cells. These are mostly used in digital design, but are available for any design style that can make use of them. Sites are defined in the technology database, and define the pattern for a given technology or package size dictating how cells may be placed in rows on the design. The rows (described below) then provide an embedding of Cellviews within a given row that map to the allowed sites described in the site definition.

The TrackPattern object implements a possibly heterogeneous grid pattern for use with grid-based routers. The patterns may be global or associated with a specific layer and purpose, allowing for different routing grids per layer. Multiple patterns may be given for different regions of a design, and it is possible to build arbitrarily complex routing grids by superposing patterns with different grid spacing.

Row objects are used to define a related row of sites on which Cellviews may be placed. They are related to a site definition from the technology file. They can be horizontal or vertical, and there can be an arbitrary number of rows in a given design.

Parameterized cells
Most intermediate layout cells have no parameters. They are built from the placement of lower-level cells and library leaf cells, and may be directly placed in a design. For certain simpler classes of low-level cells, it is useful to be able to build parameterized cells, called pcells for short. A pcell is really a simple program that takes a parameter block and generates a layout that represents the parameterized layout. In its simplest form, a via is a great candidate for parameterization. In fact, there are built-in models for parameterized vias that will meet 90 percent or more of a design's via needs.

Designers have used pcells for everything from simple devices (such as transistors and diodes) to higher-level cells (such as ALUs and bit-slices). Although layouts are the norm for pcells, netlists may be created as well. By convention, connectivity is usually fixed with pcells, but that isn't a specific requirement.

In the OpenAccess database implementation, when instances of pcells are placed, they are organized into SubHeaders inside the instance. There is an InstHeader object that links together all of the instances of a specific master that appear in a given cell. If the master is also a pcell, there are child InstHeaders referred to as SubHeaders from the InstHeader that link together all instances of the same master with the same set of parameter values. For example, if there is a transistor device with parameters W and L, one will have a single InstHeader for the transistor master. It will also have SubHeaders, one for each set of values of W and L. In the case with 3x2, 4x2, and 4x4 transistors, one would have three SubHeaders below the single InstHeader for the transistor devices.

In its internal implementation, OpenAccess is designed to allow for addition of any language as an evaluation vehicle for pcells. A C++ layer is built in that allows access to the full OpenAccess C++ API. Cadence imbeds its Lisp-like Skill language, and the complexity of some Skill-based pcells is almost legendary. Other OpenAccess members are working on bindings that allow pcells to be written in Tcl, Perl, and Python. Provisions are made within OpenAccess to deliver a shared-object language interpreter for pcell use along with a library. Application developers should note that although the OpenAccess binary data is interoperable among the set of platforms on which it is supported, the pcell interpretation code is platform-specific, and must be supported on all platforms of interest.

Parasitic models
OpenAccess version 2 supports many models for distributed and reduced representations of parasitics. A full distributed model that decomposes each net into a network of resistors, capacitors, and inductors (an RLC network) is included. The model includes two forms of coupling between nets -- lumped and distributed -- allowing for very complex parasitic descriptions.

Lumped coupling reduces the coupling between two nets to a single equivalent capacitance value. Distributed coupling allows for multiple capacitors to link the distributed models of the two nets at any given junction within the distributed network. The distributed model is much more accurate than the lumped one, but can take a great deal more storage than the simpler model.

Multiple process points are allowed. Typically, a min/max or min/typ/max form is used, but the model allows for as many process points to be stored as is desired. The model is a superset of what can be expressed in SPEF, and is much more efficient, taking less than one-third the size of the corresponding SPEF file to store the same information inside OpenAccess.

The reduced form comes in three variations. A lumped form allows reduction into the simplest of models. An Elmore variation allows reduction into a simple model with a Pi network on the output of a driver along with time delays to the load pins on the parasitic network. A pole-residue model allows expression of the reduced network in this form. All of these reduced forms are much smaller than the distributed form and are smaller than their correspondents in RSPEF, SDF, and other external reduced formats.

Technology database
The technology database in OpenAccess version 2 is quite simple. It stores information about layers and purposes (relating names to the numbers used in the design data in each case). It stores definitions of allowed layer-purpose pairs, and this information can be used by a rendering application to tie display attributes to the LPP. It contains definitions of Sites (as described above) for a given technology. It also contains ViaDefs that link via definitions (either parameterized cells or normal cells) to the symbolic via names that are used in the design data within Routes.

Many other types of information about a given technology can and will be stored in the technology DB. This is one of the ongoing areas of research that is described below in the Future Work section.

Extensibility in OpenAccess
One of the most common criticisms of an open standard is that its evolution becomes glacial. It can take years to get a significant change through the groups that control the evolution of the standard. In the context of OpenAccess, this is both a good and bad thing. It is vital to the realization of the OpenAccess vision that tools have a consistent and equivalent view of the semantics of the database.

Most of the discussion that goes on about any given point involves arriving at a common definition for the behavior of a given construct. Sometimes it seems as though the exact behavior is less important than the full (and agreed-to) definition of the behavior -- there are often many equally good ways to specify a given behavior. Taking the time to have these discussions does make progress through OpenAccess sometimes slow, but this is okay, since at the end users have a better platform for interoperability, which is the main point of OpenAccess.

That said, in practice one usually cannot wait a year or longer to get an agreed-upon extension. There will be many times that the current data model is insufficient for current or future planned needs. This is where OpenAccess extensibility comes into play. It is possible to extend any OpenAccess object with new attributes; to build new relationships among existing objects; and to define new objects and relationships among them. These definitions can be persistent or non-persistent. The efficiency of use of these extensions rivals the performance of the natively implemented objects, both in speed and in memory usage. With careful construction, the extended objects may appear to be of an identical form to the OpenAccess APIs.

This last point underscores the power of the OpenAccess extensibility mechanisms. In contrast to a paper standard, where groups would argue seemingly endlessly about one construct versus another, the OpenAccess extensibility is built for rapid and efficient prototyping. In this way, as the OpenAccess group decides to extend the core definition, multiple competing implementations may be built, and then their performance can be measured. Once hard data is gathered, implementation choices become much easier, and progress is in fact accelerated. Thus, while we may take time to come to an overall agreement on an extension, you can be guaranteed that you'll never be stuck waiting for such an extension, and that once one is implemented, it will almost certainly have been tested on real code with real data.

Future work
OpenAccess provides a folded hierarchy model. In addition to this, it needs an occurrence model, which should have both persistent and non-persistent parts. In the persistent model, one could store occurrence-specific parasitic information, for example. The context in which a cell is found can greatly affect its parasitic values, and there will need to be something like this for the highest levels of accuracy.

A non-persistent occurrence model would provide a good base on which to design new implementations of algorithms, for example, a timing engine. Properly designed, such algorithms could be incremental, would benefit from not needing to duplicate netlist and other information, and could cooperate with other incremental algorithms built on a shared occurrence model layer.

A Development Working Group for an occurrence model has been working inside the OpenAccess Change Team for one year and has a specification for a working "5-box" model. It is being unified with the logical/physical hierarchy mapping described below and will be implemented according to its final specification.

A very common need in EDA design today is to be able to relate a logical hierarchy to the physical implementation hierarchy. As engineering changes (ECOs) occur, it is necessary to feed them forward from the logical domain into the physical one while disturbing the physical implementation as little as is possible. Also, changes that occur during physical implementation (for example, buffer insertion to meet timing) must be reflected back into the logical netlist in order to go back and verify the logical function with the full details (including detailed parasitics). For both of these reasons, it is necessary to be able to relate the logical and physical hierarchies.

Many mechanisms for accomplishing this have been examined, and the best overall choice seems to be to combine the logical and physical hierarchies for a sub-block into a single design unit. The first implementation of this will result in a physical hierarchy in which is embedded the logical hierarchy levels that were used to create the physical block. As the physical block is modified during implementation (the aforementioned buffer insertion), the changes are automatically reflected back to the logical hierarchy.

Labels are used to distinguish components that have come forward from the original logical netlist and those that have been added during implementation. Thus, an ECO that preserves as much of the physical implementation is now possible. This work will be finalized and will be incorporated into an OpenAccess delivery sometime in 2003.

Cadence has developed translators to and from the OpenAccess DB for the LEF/DEF, GDS II, Verilog, VHDL, and other formats. The OpenAccess community over time will need open sourced versions of these translators to improve adoptability of the standard. Ideally, every format that can get or save data from the OpenAccess data models (SPEF, SDF, OLA, EDIF, STAMP, .LIB, TLF) should have a translator. This is where we first expect the community to help deliver on the standard. Cadence is readying its LEF/DEF and GDS II translators so they may be open sourced. Others will follow from Cadence and the other community members, as they are available.

An API-based standard like OpenAccess also needs a companion archival format. Looking at current standards, XML is the obvious choice for an archiving format that can be versioned. Some people may even choose to use such a format as the basis for an implementation (of course, the equivalent data in the reference implementation is about 20X smaller).

Currently, Cadence is working on a prototype for an XML-based archiving format. We'll standardize it though a working group of the OpenAccess Change Team and make it available when it is ready.

Constraints and rules is the biggest open area within the OpenAccess arena. Every EDA application creates constraints on the data, and has rules that guide its operation. The challenge is to unify the plethora of existing standards, each of which has a slightly different domain, many of which overlap, into a single standard that covers the gamut of IC design from structural RTL through mask creation.

We are starting to look at this in detail now. We hope to leverage existing standards where they exist, and to try and fill in the gaps where standards don't exist. Finally, one of the necessary evils of EDA design is design-data management (DDM). It seems that every group has their own preferred tools, whether they be a standard product (Synchronicity, ClearCase), an open-sourced tool (RCS, CVS), or some proprietary solution.

Given that we must support multiple standards, the best we can hope for in the OpenAccess system is to provide hooks into DDM from within the OpenAccess database. At a minimum, we must provide the ability to do "autocheckout," and ideally, we would provide a standard part of the API that would interface to the full control aspects of a DDM system. We are working with interested parties to create such a definition, and it will be made available when ready.

Summary
This paper has presented the OpenAccess version 2 data model. We have shown how the use of a unified data model allows for better integrated, higher performing SoC tool flows. We have introduced the data model, starting from basic layout shapes, adding instances and hierarchy. We have introduced the OpenAccess versions of connectivity representation, and shown how connectivity is used across hierarchy boundaries. We introduced advanced concepts of place-and-route constructs and parasitic models. We described the future work ahead of the OpenAccess Change Team.

We invite any interested parties to join the OpenAccess community and help contribute to the overall success of the OpenAccess standard. For more details on the data model and its associated APIs, or for general information on the OpenAccess program, please visit the Open EDA web site or the Silicon Integration Initiative web site.

Mark Bales serves as a Cadence corporate fellow, responsible for infrastructure-level architecture within the IC Solutions Business unit. In addition, he is one of the leaders of Cadence's efforts to develop the OpenAccess Database. Bales was a founder of SDA Systems, one of two companies that merged to form Cadence. During a hiatus from Cadence, Bales co-founded High Level Design (HLD) Systems, which became the leader in the market for IC floor planning tools.

Joseph Santos is the lead architect and development manager for the OpenAccess development Group at Cadence. Since joining SDA Systems (now Cadence Design Systems) in 1984, Mr. Santos has led various development groups, including the Analog Artist Physical Design System and the Virtuoso Physical Design System.

Irwin Diehl is senior technical publications consultant at Cadence.