 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
The OpenAccess Embedded Module Hierarchy is enhanced in several areas, which are listed next in relative order of importance:
See also, the Programmers Guide article Understanding OpenAccess Hierarchy.
The occurrence hierarchy can cover a full design hierarchy derived from multiple oaDesign objects. The occurrence hierarchy is built as you traverse it using the following API:
oaOccInst::getMasterOccurrence()
The full hierarchy is saved persistently using
oaDesign::save()
Only annotations such as properties, extensions, and parasitics are saved with the top design. The original oaDesigns must be read again when the occurrence hierarchy is read.
The connectivity consisting of nets, instances, and terminals are stored in the oaDesign for the masters of the occurrence objects only. If the design is edited when the occurrence hierarchy is in memory, the connectivity is kept in synch with the occurrence objects. If the design is edited in a different context, the database compares the time stamps and invalidates the occurrence tree beneath all instances of a changed master. The occurrence hierarchy must be re-expanded in each session by calling getMasterOccurrence.
A module hierarchy, in a given oaDesign, can be aggregated from separate oaDesigns using the following API to embed the separate designs:
oaModule::embed(oaDesign* destination,
const oaDesign* master)
This is a static method on oaModule that creates a module hierarchy, which is copied from the master. The oaModDesignInsts associated with this master are converted to oaModModuleInsts that point to the new module. The names of all the new modules must be unique, otherwise, the database auto-names the imported modules. The master oaDesign is not changed in any way.
A module hierarchy can be broken out or detached from a given oaDesign and placed into a new oaDesign in order to repartition a design. You use the following API to detach a module hierarchy from an oaDesign:
oaModule::detach(oaScalarName &libName,
oaScalarName &cellName,
oaScalarName &viewName,
oaDetachVisibilityEnum)
This function creates a new oaDesign with the module hierarchy beneath the module that is copied to it. The oaModModuleInsts associated with this master are converted to oaModDesignInsts that point to the new oaDesign. The modules that are used only in the detached hierarchy are removed from the starting oaDesign.
There is now a single InstHeader in each oaDesign for each master oaDesign that is referenced. These are the InstHeaders for oaModDesignInsts only, not for oaModModuleInsts. The collection supports a scope to a parent module that can be used to provide the traversal to ModInsts within a given parent.
oaCollection oaModInstHeader::getInsts(oaUInt4 filterFlags=oacInstIterNotImplicit,
oaModule * module)
Edits in the block domain to objects that are derived from folded module objects require the module to be uniquified. In this case, the module object corresponds to two or more block objects. If one of these block objects is changed, the module must be split into two variants. When modules are uniquified, many object pointers become invalid, and it is too complex to automatically identify which object pointers become invalid. In OpenAccess 2.2, this uniquification must be done explicitly by the application.
In version 2.2, OpenAccess modules have a single name like other database objects. You use the following API to assign a module name:
oaModule::create(oaDesign *design,
oaScalarName &name)
If a module is uniquified, the database remembers which module it started from. The following API identifies the original source module:
oaModule::getOrig(oaScalarName name,
oaScalarName libName,
oaScalarName cellName,
oaScalarName viewName)
Several additional oaModule functions show the relationships between a variant and source module:
oaBoolean isDerived()
oaBoolean isEmbedded()
oaBoolean isVariant (oaModule *module)
oaBoolean isClone (oaModule *module)
oaBoolean isMasterModified (oaModule *module)
The classes oaOccNet and its children, and the classes oaOccInst and its children, have getName and a getPathName member functions.
For example, if getName returns mbuf, getPathName might return cp1.mem0.mbuf, which is the name from the top of the occurrence hierarchy.
In order to simplify the identification of a flattened set of nets, there are new functions to return the set of global nets in an occurrence hierarchy. You can get a representative net for each global name in an occurrence hierarchy by using the following API:
oaCollection <oaOccNet, oaOccurrence> oaOccurrence::getNets(oacNetIterGlobal)
You can get all the other occNets with the same name in the hierarchy by using:
oaCollection <oaOccNet, oaOccNet> oaOccNet::getGlobalNets()
When equivalent nets are specified in the module domain, where possible, EMH preserves these in the block and occurrence domains. This is different from most flattening algorithms. In addition, OpenAccess provides flags on collections for applications that want to ignore equivalent nets.
oaCollection oaNet::getTerms(oaUInt4 filterFlags)
The flag oacTermIterEquivNets determines whether the collection gets terms from all nets that are equivalent to the given net. To obtain the preferred equivalent net, set the preferred argument of oaTerm::getNet() to true:
oaNet * oaTerm::getNet(oaBoolean preferred = false)
Parasitics can be placed on both an oaOccNet and its corresponding oaNet. This allows parasitic extraction to the oaNets in a block, which then allows them to be stitched into a single model that is placed on an oaOccNet.
The connection object on an oaNode at a hierarchy boundary is the term or instTerm at that boundary. Usually, it is easy to align these by finding the corresponding term or instTerm and getting its node. Note that the connection object of an oaNode may not be a Pin or an InstPin in version 2.2. In some complex cases where a terminal has multiple pins, or a pin is extracted into multiple nodes, they must be compared using their coordinates. However, this is not supported by SPEF.
The verilog2oa translator can read an entire Verilog source into a single oaDesign and create a module hierarchy for it. Each Verilog module becomes an OpenAccess module. Modules that are not used in the hierarchy under the top module are removed.
def2oa can add physical-only objects to a Verilog hierarchy. It cannot create a module hierarchy, but it can annotate on top of a Verilog hierarchy. This form of annotation requires a file with hierarchical names.
Copyright © 2003-2010 Cadence Design Systems, Inc.
All rights reserved.