 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
Inheritance diagram for oaModTerm:
 |
 |
Public Methods | |
| void | destroy () |
| oaBoolean | isImplicit () const |
| oaBoolean | isInterface () const |
| oaModBitTerm * | getBit (oaUInt4 bitIndex) const |
| oaModNet * | getNet (oaBoolean preferred=false) const |
| oaUInt4 | getNumBits () const |
| oaTermType | getTermType () const |
| oaUInt4 | getPosition () const |
| void | getName (oaName &name) const |
| void | getName (const oaNameSpace &ns, oaString &name) const |
| void | moveToNet (oaModNet *net) |
| void | setTermType (oaTermType termType) |
| void | setIsInterface (oaBoolean isInterface) |
| void | setPosition (oaUInt4 position) |
| void | unsetPosition () |
| void | scalarize () |
| oaCollection< oaOccTerm, oaModTerm > | getOccTerms (const oaOccurrence *top) const |
Static Public Methods | |
| oaModTerm * | create (oaModNet *modNet, const oaName &name, oaTermType termType=oacInputOutputTermType) |
| oaModTerm * | find (const oaModule *module, const oaName &name) |
| oaModTerm * | find (const oaModule *module, oaUInt4 position) |
| oaBoolean | isValidName (const oaModNet *net, const oaName &name) |
| oaUInt4 | getMaxPosition (const oaModule *module) |
Public Types | |
| enum | { dtIndex = oacTermDataType } |
oaModTerm, oaOccTerm, and oaTerm each represent terminals on a different kind of master, where in each case the master represents a level of hierarchy in the design.
For oaModTerm, the master is an oaModule, and each module in a design will have a set of zero or more modTerms.
For oaTerm, the master is an oaBlock, and the top block for the design will have a set of zero or more modTerms. Typically, many of the oaTerms on the top oaBlock have a corresponding oaModTerm on the top oaModule. All of the oaTerms on the top oaBlock have a corresponding oaOccTerm on the top oaOccurrence.
Note that oaModTerm::getOccTerms will return oaOccTerms only if the occurrence hierarchy has been expanded to include those objects. See Working in the Occurrence Domain for more details.
When oaTerm objects are created in the block domain, the corresponding oaModTerm objects are automatically created on the top oaModule unless the domain visibility is set to oacExcludeFromModuleDomain.
Multi-bit terminals represent a group of logical connections to import or export from the module. The terminals can consist of busTerms having a single root name with an index range, or they can include bundleTerms that are a more complex grouping of terminals. Multi-bit terminals can have overlapping names. For example, you can have the busTerms "addr<7:0>" and "addr<3:0>" as long as the overlapping bits are connected to the same nets.
OA requires a consistent definition of single and multi-bit terminals shared between the top module and the top block in a design. When an oaBusTerm has been created that is not visible in the module domain, it is not possible to create an oaModBusTerm that uses the same base name. Similarly, it is not possible to create an oaModScalarTerm whose name would conflict with any oaScalarTerm or oaBusTerm in the block domain.
All oaModBusTerms with the same root name are managed by an oaModBusTermDef. The oaModBusTermDef tracks the least significant and most significant bits of all the associated oaModBusTerms, all of the oaModBusTerms with the same base name, and all of the associated oaModBusTermBits.
oaModBusTermBits are automatically created for each bit of an oaModBusTerm, if they do not already exist. oaModBusTermBits are available for those applications performing scalarized connectivity traversal of the data.
oaModBundleTerms can contain oaModScalarTerms or oaModBusTerms. When an oaModBundleTerm is created, the constituent scalarTerms and busTermBits are automatically created in addition to the bundleTerm itself. All automatically created terminal objects are considered implicit.
Names are associated with terminals. The various terminal objects take and return names through the general oaName object but also use the oaScalarName, oaVectorBitName, oaVectorName, and oaBundleName objects. These name objects manage the mapping of names from one nameSpace to another. For example, you can create a terminal using a name in the CDBA nameSpace. Another application can retrieve the terminal name in the Verilog nameSpace directly from the database.
The oaModTerm class can be observed by deriving from oaObserver<oaModTerm>.
|
||||||||||||||||
|
This will create a new ModTerm on the specified net. This function can create scalar, busBit, bus, and bundle terminals. The exact type of module terminal depends on the type of the oaName that is supplied.
|
|
|
This function removes the ModTerm from its module and design.
|
|
||||||||||||
|
This function the specified module for a terminal assigned to the specified position. The terminal is returned if found. Otherwise, NULL is returned. If a reflected block domain terminal is hidden, or is hidden and overridden, this function always returns the terminal corresponding to the hidden object.
|
|
||||||||||||
|
This function searches the terminals in the specified module for the one with the specified name. The terminal name cannot be hierarchical since a terminal is local to an instance. If the terminal is found, it is returned. Otherwise, NULL is returned. If a reflected block domain terminal is hidden, or is hidden and overridden, this function always returns the terminal corresponding to the hidden object.
|
|
|
This function returns a pointer to the bit terminal that corresponds to the specified bitIndex bit of this terminal. For single-bit terminals, this function returns a pointer to itself. For multi-bit terminals, a busTermBit is returned if this terminal is a busTerm, or a bit terminal is returned if this terminal is a bundleTerm. If the reflected terminal in the block domain is hidden, the returned oaModBitTerm pointer corresponds to the reflected hidden terminal.
|
|
|
This function returns the highest position occupied by a terminal in the specified module. If there are no terminals in the module or no position has been assigned a terminal, the value oacNullIndex is returned.
|
|
||||||||||||
|
This function fills in name with the name of this terminal mapped to the specified nameSpace. |
|
|
This function fills out name with the name of this terminal. |
|
|
This function returns the net to which this terminal is attached. If preferred is true, the preferred equivalent net associated with the net will be returned instead.
|
|
|
This function returns the number of bits in this terminal. |
|
|
This function returns a collection of all the occurrence terminals that correspond to this module terminal. There can be multiple such occurrence terminals because of folding in the module hierarchy that results in one occurrence terminal for each path to this module from the top of the occurrence hierarchy. This function returns NULL for occTerms that correspond to hidden block terms, even if the occTerm corresponds to a modTerm in the top module.
|
|
|
This function returns the position that this terminal is assigned to. The value oacNullIndex is returned if this terminal has not been assigned to a position. |
|
|
This function returns the terminal type of this terminal. |
|
|
This function returns a boolean value indicating whether this terminal is implicit. An implicit terminal is automatically created by the database as part of the explicit creation of a multi-bit terminal. |
|
|
This function returns a boolean indicating whether this terminal is an interface terminal. An interface terminal is one that was explicitly created by an application calling one of the create functions on the objects derived from oaTerm. Explicitly created terminals define the interface to the block that contains them. Note that an interface terminal that is scalarized is still considered an interface terminal. Implementation data may be added to the resulting bitTerms after scalarization, but the interface terminal remains as a reference to how the interface was originally defined. Further edits to the block may delete the interface terminal, indicating that the interface to the block has indeed changed. |
|
||||||||||||
|
This function returns a boolean value indicating whether the specified name, associated with the specified net, is valid for a new oaModTerm object. |
|
|
This function moves this terminal to the specified net.
|
|
|
This function insures that the bitTerms associated with this terminal have been promoted to the explicit state so that they can support implementation data such as pins and routes. If this terminal is a multibit terminal, this function insures that all constituent bitTerms are promoted to the explicit state. The multibit terminal is then demoted to the implicit state so that no implementation data can be associated with it. When a terminal is demoted to the implicit state, associated implementation data is removed from it. The demotion of a multi-bit terminal has no affect on whether the terminal is an interface terminal (a terminal that was explicitly created defines the original interface for its corresponding block).
|
|
|
This function changes the isInterface value for this terminal. For more information, see oaModTerm::isInterface.
|
|
|
This function assigns or changes the position of this terminal to the specified position. It is an error to assign a position to an implicit terminal. It is also an error to specify a position that is assigned to another terminal.
|
|
|
This function changes the terminal type for this terminal.
|
|
|
This function clears the position this terminal is assigned to, freeing the position so that another terminal can be assigned to it. Nothing is done if this terminal is not currently assigned a position.
|
|
|
|
Copyright © 2002 - 2010 Cadence Design Systems, Inc.
All Rights Reserved.