Table of Contents Previous Chapter

3 The Information Model

One of the primary tasks of the Design Representation Working Group was to define a common Information Model (IM) for design representation. This IM serves as the basis for the Design Representation Programming Interface (DR-PI), which can be used by CAD tools to manipulate design information.

NOTE: While every effort has been made to ensure the accuracy of the IM, if there are any discrepancies between the IM and the DR-PI, the definitions in the DR-PI will take precedence.

3.1 Structure of the Information Model Description

The remainder of this section provides a detailed description of an Information Model for representing electronic circuits. Ultimately, most aspects of circuit structure (i.e., schematics, layouts, and netlists) will be represented. However, at present, hierarchical netlist connectivity is the single aspect covered by this model.

In an effort to manage the definition process, the IM has been partitioned. Each major portion of the model is described in a separate section using textual descriptions and information model diagrams. The most primitive or low-level concepts are described first, followed by descriptions of additional entities and types needed to build up to the final model.

As mentioned previously, the information model described in this document will be constructed in the EXPRESS language [1]. One of the primary goals for using EXPRESS is to capture the information model explicitly in a computer readable format. EXPRESS provides a syntax for defining data types, data entities, the behavior among entities, and inheritance among the definition of entities. This description will include "fragments" of the EXPRESS text corresponding to the concept being described. These fragments do not represent the entire model. For example, this section does not present the definition of the function unique_names(). Refer to Appendix A for the entire EXPRESS text description of the DR connectivity model including any functions used, such as unique_names(). Refer to [1] for a description of the EXPRESS language. All of the diagrams in this document are drawn using the EXPRESS-G graphical notation which is briefly explained in the next section. Refer to [1] also for a detailed description of EXPRESS-G.

The first diagram is shown in Figure 3.1, "Base Object Model Diagram," and is described in Section 3.3. The base object model captures the top of the entity hierarchy used to describe the information model.

The second diagram, shown in Figure 3.2, "Base Connectivity Model Diagram." This model represents a high-level abstraction of the basic connectivity model for electronic circuits.

3.2 Description of EXPRESS-G

EXPRESS is a language used to model information. The language is described in the ISO document, EXPRESS Language Reference Manual, TC184/SC4 WG5 Document N14 [1]. EXPRESS can be used to model:

All of the information models presented in this document will be described formally in the EXPRESS language (refer to Appendix A, "Information Model").

EXPRESS is a language. Hence, information models written in EXPRESS are textual. However, a graphical notation has also been defined, dubbed EXPRESS-G. This notation is described in detail in Annex D of the document cited above. However, since EXPRESS-G is a new notation for many readers, a brief description is provided here.

EXPRESS-G is a graphical notation for the display of information models. The notation only supports a subset of the EXPRESS language, and therefore EXPRESS-G models are normally abstractions of EXPRESS models [1]. There are equivalent notations for bit-mapped graphics and ASCII character or "typed" diagrams. EXPRESS-G has symbols to represent EXPRESS entities, user-defined types, base types, relationships (required and optional), and inheritance. Table 3.1, "Express-G Legend", provides a legend for understanding EXPRESS-G diagrams.

Table 3.1 EXPRESS-G Legend

The small circle on the end of relationship arcs indicates direction only; it has nothing to do with cardinality. The cardinality of a relationship will be annotated on the relationship using text. Refer to the EXPRESS manual [1] for more informati on about EXPRESS-G.

3.3 The Base Object Model

The entire Design Representation Information Model is derived from a single entity which models the basic, low-level behavior of any entity in the model. This low-level behavior is intended to capture the essence of the notion of an object. The basic behavior of all objects in the DR model is that they will be typed and may have an optional list of properties associated with them. Additionally, many objects will have a name. The EXPRESS-G diagram for this basic object model is shown below in Figure 3.1 as an entity-level model. Following the figure is a more-detailed description of the entities and types depicted in the diagram.

Figure 3.1 Base Object Model Diagram

3.3.1 Type: ObjectType
TYPE cfidrObjectTypeT = ENUMERATION OF ( 

   CFIDR_CELL,

   CFIDR_INST,

   CFIDR_LIB,

   CFIDR_NETBUNDLE,

   CFIDR_NETBUS,

   CFIDR_NETSCALAR,

   CFIDR_PORTBUNDLE,

   CFIDR_PORTBUS,

   CFIDR_PORTINSTBUNDLE,

   CFIDR_PORTINSTBUS,

   CFIDR_PORTINSTSCALAR,

   CFIDR_PORTSCALAR,

   CFIDR_PROP,

   CFIDR_ENCAPSULATEDVIEW,

   CFIDR_NETLISTVIEW

   );

END_TYPE;
3.3.2 Type: ObjectId
TYPE cfidrObjectIdT = INTEGER; END_TYPE;
TYPE  cfidrCellIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrEncapsulatedViewIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrInstIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrLibIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrNamedObjectIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrNetIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrNetBundleIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrNetBusIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrNetScalarIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrNetlistViewIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortBundleIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortBusIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortInstIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortInstBundleIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortInstBusIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortInstScalarIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPortScalarIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrPropIdT = cfidrObjectIdT; END_TYPE;

TYPE  cfidrViewIdT = cfidrObjectIdT; END_TYPE;
NOTE: The Architecture Working Group has decreed that all machines of the same processor architecture have a common cfidr.h header file and that the Object IDs should be twice the size of void * (i.e., twice the size of an address).
CONSTRAINT
IDs are valid for the current session only. Hence, IDs cannot be stored in a persistent database.

In order to minimize a tool's need to explicitly test the type of an object, each type of object has a specific type for its ID. Therefore a tool usually should only need to determine whether a particular ID is valid.
3.3.3 Entity: Object
ENTITY cfidrObject

  ABSTRACT SUPERTYPE OF (ONEOF

 (cfidrNamedObject, cfidrPortInst));

  ObjectType:  cfidrObjectTypeT;

  ObjectId:    cfidrObjectIdT;

  Props:       SET [0:?] OF cfidrProp;

WHERE unique_names(Props);

END_ENTITY;
CONSTRAINT
The Name attribute of properties must be unique within the scope of a single object. That is, no two properties associated with one object may have identical names.
3.3.4 Entity: NamedObject
ENTITY cfidrNamedObject

  SUBTYPE OF (cfidrObject)

  ABSTRACT SUPERTYPE OF (ONEOF(cfidrProp, cfidrLib,

                cfidrCell, cfidrView, 

                cfidrPort, cfidrNet, cfidrInst));

  Name:  cfidrStringT;

END_ENTITY;
3.3.5 Entity: Prop
ENTITY cfidrProp 

  SUBTYPE OF (cfidrNamedObject);

  ValueType: cfidrValueTypeT;

  PropValue: cfidrPropValue;

  Owner:     cfidrObject;

END_ENTITY;
CONSTRAINT
When a Prop is removed, any Props associated with it are also removed.
3.3.6 Type: ValueType
TYPE cfidrValueTypeT = ENUMERATION OF

  (CFIDR_UNDEFINED_VALUETYPE, CFIDR_INT32, CFIDR_STRING,

   CFIDR_FLOAT32, CFIDR_BOOLEAN);

END_TYPE;
TYPE cfidrPropValue = SELECT

 (cfidrBooleanT, cfidrInt32T, cfidrFloat32T, cfidrStringT);

END_TYPE;

3.4 Overview of the Base Connectivity Model (BCM)

This section describes the portion of the model that represents hierarchical netlist connectivity. The Base Connectivity Model (BCM) is shown in Figure 3.2.

Figure 3.2 Base Connectivity Model Diagram

This model represents the objects and relationships used to represent hierarchical netlists with bundles in CFI 1.0.0 Design Representation.

In Figure 3.2 there is no modeling significance to the gray entities, they are just to highlight the "main" entities in the model.

The following two sections describe the model shown in Figure 3.2. First, a conceptual description is given for the technique of representing connectivity using the model. Following that is a detailed description of each entity and type in the BCM diagr am and the constraints on their behavior.

3.5 Base Connectivity Model Tutorial Description

Although the probability is high that anyone reading this document has knowledge of hierarchical circuit connectivity and is familiar with at least one system for representing it, there is a reason for presenting an overview in tutorial fashion here. Specifically: the model asserts throughout rules about how entities in it are to be combined to represent a hierarchical netlist. This tutorial describes the entire model and all the rules in one place. Each of the rules will be stated again as constraints on the entities defined later in this section.

Hierarchical design supports the notion of building up the behavior of a design by collecting and connecting together other designs. Each of the other designs can in turn be built from yet other designs, etc., recursively until a subdesign is reached which is composed of primitive design elements. In this case a primitive design element is one for which no further interior structure is known. Primitive design elements are also referred to as leaf cells.

A bottom-up example is to use a transistor as a primitive element or leaf cell. Transistors then are used to build and-gate, nand-gates, inverters, etc. These gates are used to build an exclusive-or-gate, which is used with other gates to build an half-ad der cell, which is used with other cells to build an adder cell, which is used with other cells to build an ALU, etc.

In order to represent a hierarchical design, there must be a way to represent the design under consideration and the fact that it is composed of other designs which are connected in some way. In the model described herein, a particular implementation of a design is represented by the NetlistView entity. The inclusion of smaller designs of which a NetlistView is composed are represented by the Inst entity. The term Inst is an abbreviation for the word Instance.

Instantiation is the act of using one design in the structure of another design. In this model, the design which is being used is the Inst, and the design in which an Inst is used is the NetlistView. As an analogy, think of the NetlistView as a printed circuit board and an Inst as a chip which is soldered down onto the circuit board. A NetlistView may have more than one Inst within it and multiple Insts of a single design may be placed into a NetlistView. An Inst represents the use of one design within an other design. Each Inst represents an instantiation of one NetlistView within another NetlistView.

An instantiation is not exactly a copy nor is it exactly a symbolic reference. For example, in a NetlistView named "Half-Adder" an Inst of a NetlistView named "XOR" represents the fact that the design of an xor gate is used as a component in the design of a half-adder.

Having provided a representation for the hierarchical structure of designs using the NetlistView and Inst entities, it is necessary next to provide a representation for interconnecting the Insts within a NetlistView.

The connectors of a design are represented by the Port entity. A Port has a name and a direction. The direction of the Port defines how signal information flows through the Port. A signal either flows into the design or out from the design through the Port. Or, in some cases, a Port is bidirectional and can conduct signal information both into and out of a design.

The pins of an Inst are represented by the PortInst entity. Since an Inst represents the use of a specific NetlistView, the PortInsts belonging to an Inst correspond exactly to the Ports on the NetlistView referenced by the Inst. For example, if an Inst "xor1" represents the use of an XOR gate within a design then each of that Inst's PortInst entities will correspond to a single Port entity in the NetlistView of the XOR gate that was used to create this Inst. The correspondence between an Inst and the Net listView it represents is referred to as the "Describer Relationship". An Inst is completely "described" by the NetlistView it represents. This same corresponcence exists between a PortInst and the Port it represents. Both the Inst and PortInst entitie s contain a Describer attribute.

The fact that PortInst's attributes for name and direction are DescriberName and DescriberDirection indicate the close tie required between each PortInst and its Describer Port. See Section 6, "View Selection", on how this very tight relationship between Insts/PortInsts and their Describers/Ports can be relaxed. View Selection provides a mechanism to specify rules for choosing an alternative (substitutable) NetlistView (and its correspo nding Ports) for any given Inst.

To complete the initial model, the Net entity is used to represent each set of connections between PortInsts and Ports within a NetlistView. When a collection of PortInst and Port entities are associated with a Net, it reflects the intention that each PortInst and Port in the collection will have exactly the same signal information at all times. A Net may connect only PortInsts, only Ports, or a mixture of the two.

One final concept is that of bundles. In many scenarios, it is convenient for a designer to group a set of signals together and refer to the set as single signal. An example of this is the RS-232 standard signal set for the interconnection of serial communication equipment. The RS-232 standard defines the set of signals expected to be found in the 25 pin connectors common on most telephone modems used to interconnect computer systems. An RS-232 cable has multiple wires which are bundled together into a single cable which can be connected once. In electronic design, there are times when it is convenient to refer to the RS-232 signal collection as a single signal, and there are times when it is necessary to refer to each individual signal separately. The same is true with respect to the connectors for RS-232 signals. The RS-232 connector bundles together 25 individual connectors.

In the BCM, this concept is represented by introducing the notions of Scalar, Bundle, and Bus. A Scalar is an individual thing which may not be unbundled into anything else. A Bundle is an ordered collection and a Bus is an ordered collection with index values for each position. The idea of Scalar, Bundle, and Bus is applied to Nets, Ports, and PortInsts.

A Net may be either a NetScalar, a NetBundle, or a NetBus. In a sense, there are now 3 "types" of Net entities. A NetScalar entity represents one individual signal which may not be further decomposed into subsignals. A NetBundle entity is a collection of Nets, each of which is optionally a NetScalar (with no further substructure), a NetBundle, or a NetBus. A NetBus entity is a NetBundle with two additional attributes of Start and Step which define the range of Index values associate d with the Positions in the bundle.

Thus NetBundles have only the Names for each Net and an implicit Position in the bundle for each Net. NetBusses are NetBundles that also have an Index value for each position. This Index is restricted to be monotonically changing from position to position by a fixed integer Step (positive or negative) but may Start at any integer value.

NetBundles do not hide the Names of their member nets. All Nets in any one NetlistView are required to have unique names. Nets can appear in more than one position in a given bundle and in more than one NetBundle. A given name for a Net in a part icular NetlistView always refers to the exact same Net.

A similar structure exists for Ports and PortInsts, resulting in the definition of PortScalars, PortBundles, PortBusses, PortInstScalars, PortInstBundles and PortInstBusses. The PortInstBundles (and PortInstBusses ) get their structure entirely from the corresponding PortBundles (and PortBusses).

However, a significant difference from NetBundles is that PortBundles hide the Names of their members from other PortBundle contents (and from the names of the Ports that are directly in the NetlistView). Thus Port Names may be reused without refe rring to the same object. The other difference is that a PortBundle (and thus also a PortInstBundle) cannot repeat a member in two different positions, therefore any one name only appears one time in a given bundle.

The rules covering the interconnection of Ports and PortInsts using Nets are complicated. To help clarify the explanation, the phrase "in-a-bundle" will be appended to the terms NetScalar, PortScalar, and PortInstScalar to distinguish items contained by a bundle from items NOT contained by a bundle.

As explained prior to introducing the notion of a bundle, a Net represents a connection between Ports and/or PortInsts. So it follows that a NetBundle will represent a connection between collections of Ports and PortInsts. The following rules summarize t he bundle connectivity model:

A NetScalar connects to [0:?] (read as zero or more) Port[inst]Scalars;
A Port[Inst]Scalar is connected to [0:1] (read as zero or one) NetScalar(s).
When a Net that is in one (or more) NetBundle(s) connects to a Port[inst] that is in a Port[Inst]Bundle, this implies a connection between all NetBundles containing the Net to the Port[Inst]Bundle containing the Port.
A NetBundle connects to [0:?] Port[Inst]Bundles.
A Port[Inst]Bundle is connected by [0:?] NetBundles.

Disallowed Connections:

A NetScalar connects to NO Port[Inst]Bundles directly. Port[Inst]Bundles are NOT directly connected by a NetScalar.
A NetBundle connects NO Port[Inst]Scalars directly;
A Port[Inst]Scalar is NOT directly connected by a NetBundle.

Shorted Ports

The connection of multiple PortScalars to one NetScalar creates a short between the PortScalars. This also means that the NetScalars connected to the PortInstScalars which are instantiations of the shorted PortScalars are electrically equivalent. Thus, th eir names are aliases of each other.

NetBundle-PortBundle Asymmetry

Why are bundled Nets and Ports treated differently? Many people initially expect them to be symmetric, since a Port is conceptually just a special Portion of a Net. But there are two reasons for this lack of symmetry:
(1) cell content descriptions are substantially simplified, and
(2) the cascading delete requirements are different for Nets and Ports.

These are each explained in more detail below:

(1) Simplified Logical Connectivity Descriptions
The simplification comes from the elimination of complex facilities to represent the ripping of NetBundles to connect their constituents to other NetBundles or scalars. Instead, the default basis for Net connectivity within a cell is by unique Net name within the cell. That is, any scalar or bundle named X in a cell is the same scalar or bundle (connected to be electrically the same), where X may be any name. In fact, since they are the same, we no longer even think in terms of connectivity. All ap pearances in a cell of a Net (Scalar, Bundle, or Bus) named X are simply the same scalar, bundle, or bus.

This principle applies to each NetlistView of a cell. Each NetlistView has its own separate Net name scope. However, NetScalars whose IsGlobal attribute is true are global in name scope such that all appearances of the same name on any global NetSc alar represent the same NetScalar. That is, all global NetScalars with the same name carry the same electrical signal.

Thus, while Nets may be "connected" by name inside a view, Net to Port connections cannot be by name. Since Port names are available outside the view, they are likely to be different as external needs require. Net to Port connections therefore must be exp licitly expressed, and not left to default. Therefore Net to Port or Net to PortInstance connections must be explicitly expressed or connected by the matching order of bundle constituents.

(2) Cascading Deletion Semantics
Secondly, the deletion semantics for NetBundles and PortBundles are different. The deletion of a NetBundle must not cascade to delete the scalars within the NetBundle. NetScalars are the essence of the design, and NetBundles are just an artifact for conve nience. Conversely, the deletion of a PortBundle is the removal of that Port and all its constituents from the external appearance of the view. Thus, deletion of a PortBundle cascades to also delete all the constituent Ports within that PortBundle.

3.6 Base Connectivity Model Detailed Description

In this section, each entity in the BCM is described in detail. The content of the information for each entity is described along with any constraints on the behavior of the entity.

3.6.1 Entity: Lib
ENTITY cfidrLib 

  SUBTYPE OF (cfidrNamedObject);



  Cells:     SET [0:?] OF cfidrCell;



  WHERE

  unique_names(Cells);

END_ENTITY;
The Name attribute for a Lib (inherited from NamedObject) is a single string which labels the Lib.

CONSTRAINT
A Lib's Name attribute must be unique with respect to all other lib names known by the current PI session.

When a Lib is removed from a session (purged or destroyed), all the Cell and Prop objects contained by the Lib become inaccessible in the session.
All Libs accessible during a session must have unique names.
3.6.2 Entity: Cell
ENTITY cfidrCell

  SUBTYPE OF (cfidrNamedObject);



  Owner:     cfidrLib;

  Views:     SET [0:?] OF cfidrView;

  

  WHERE

  unique_names(Views);

END_ENTITY;
CONSTRAINT
A Cell's Name attribute must be unique with respect to the names of all Cells in the set of Cells in the Owner Lib.

Purging or destroying a Cell within a session causes any View and Prop entities owned by the Cell to become inaccessible.
3.6.3 Entity: View
ENTITY cfidrView



  SUBTYPE OF (cfidrNamedObject)

  ABSTRACT SUPERTYPE OF (ONEOF

  (cfidrEncapsulatedView, cfidrNetlistView));



  Owner: cfidrCell;

  ViewType: cfidrStringT;



END_ENTITY;
CONSTRAINT
A View's Name attribute must be unique with respect to all View names within the scope of a Cell.
3.6.4 Entity: EncapsulatedView
ENTITY cfidrEncapsulatedView



  SUBTYPE OF (cfidrView);



  Key: cfidrStringT;



END_ENTITY;
NOTE: No mechanism is provided to access ports or other aspects within an EncapsulatedView. An EncapsulatedView must either already have internally-named Ports with the same names as used in the other Views, or some tool-specific mechanism must be u sed to relate between them.
3.6.5 Entity: NetlistView
ENTITY cfidrNetlistView



  SUBTYPE OF (cfidrView);



  Ports:    LIST[0:?] OF cfidrPort;

  Nets:     SET [0:?] OF cfidrNet;

  Insts:    SET [0:?] OF cfidrInst;

  

  WHERE 

  unique_names(Insts);

  unique_names(Nets);

  unique_names(Ports);  



END_ENTITY;
The NetlistView entity models the structure and electrical connectivity of a hierarchical netlist. It is similar in scope to the EDIF 2 0 0 NETLIST [5] view. Electrical connectivity refers here to the logical or electrical connections that carry logical o r electrical signals within and between the cells in the design.

Ports represent the "places" on the NetlistView where connections can be made to instances of this view. They provide access to the signals inside this view.

Insts represent the hierarchical references to (or inclusion of) other NetlistViews in the definition of this NetlistView.

Nets represent the signal carrying connections between the Ports of this NetlistView and PortInsts. PortInsts are located on Insts and correspond to the Ports of the NetlistViews that describe each Inst.
Port, Net, Inst, and PortInst are each described further in the sections on those entities.

In future versions of the model, the NetlistView entity may be further refined into sub-types to distinguish between "contents" views with substructure (nets and insts) and "interface" views without substructure (ports [and maybe nets] only). Another dist inction can be made (as in the new EDIF 3 0 0) between logical connectivity and the structure used in implementing it with specific objects such as the graphics in a schematic or a symbolic layout view. For instance, additional structure is imposed on th e connectivity in a schematic by junctions, rippers, and off-page connectors.

CONSTRAINT
Each Port's Name attribute must be unique with respect to the names of all other Ports in the list of Ports.

Each Inst's Name attribute must be unique with respect to the names of all other Insts in the set of Insts.

Each Net's Name attribute must be unique with respect to the names of all other Nets on the set of Nets.
3.6.6 Entity: Inst
ENTITY cfidrInst

  SUBTYPE OF (cfidrNamedObject);



  Owner:       cfidrNetlistView;

  Describer:   cfidrNetlistView;

  PortInsts:   LIST [0:?] OF cfidrPortInst;

END_ENTITY;
CONSTRAINT
A NetlistView may not instantiate itself either directly or indirectly. In other words, none of the instances in a view may be of that same view nor may they be of views which have instances of that same view or instances of views which have instances of that same view, etc. Simply put: no recursive instantiation is allowed. This however does not preclude instantiating another view of the same cell---something that might be done to collect views into pages, for instance.
NOTE: The Programming Interface is only required to check for direct recursion because of the computational cost associated with checking for arbitrary indirect recursion.
3.6.7 Entity: Port
TYPE 

  cfidrPortOwner = SELECT 

    (cfidrNetlistView, cfidrPortBundle);

END_TYPE;
ENTITY cfidrPort

  SUBTYPE OF (cfidrNamedObject)

  ABSTRACT SUPERTYPE OF ONEOF

    (cfidrPortScalar, cfidrPortBundle);



  Owner:      cfidrPortOwner;

DERIVED

  Position: cfidrInt32T find_position_in_owner();

END_ENTITY;
NOTE: Ports have position regardless of whether the Owner is a NetListView or a PortBundle; in both cases they are on a list of Ports.
CONSTRAINT
The Name attribute of a Port must be unique with respect to the Name attribute of every other Port on the list of Ports in the Owner (NetlistView or PortBundle).
3.6.8 Entity: PortScalar
ENTITY cfidrPortScalar

  SUBTYPE OF (cfidrPort);


  Direction:  cfidrPortDirection;

  NetScalar: OPTIONAL cfidrNetScalar;

END_ENTITY;
3.6.9 Type: PortDirection
TYPE cfidrPortDirection = ENUMERATION OF 

      (CFIDR_UNDEFINED_PORTDIRECTION,

       CFIDR_INPUT,

       CFIDR_OUTPUT, 

       CFIDR_IO);

END_TYPE;
3.6.10 Entity: PortBundle
ENTITY cfidrPortBundle

  SUBTYPE OF (cfidrPort)

  SUPERTYPE OF (cfidrPortBus);


  Ports:       LIST [0:?] OF UNIQUE cfidrPort;

  NetBundles:   SET [0:?] OF cfidrNetBundle;

DERIVED

  Size:  SIZE_OF(Ports);

END_ENTITY;
CONSTRAINT
PortBundles may not recursively contain themselves either directly or indirectly. The PI is required to check for direct recursion at PortBundle creation time but not to check for indirect recursion at that time due to the potential computational cost.
3.6.11 Entity: PortBus
ENTITY cfidrPortBus

  SUBTYPE OF (cfidrPortBundle);


  Start: cfidrInt32T;

  Step:  cfidrInt32T;

END_ENTITY;
CONSTRAINT
In spite of the fact that, for some systems, the distinguishing characteristic of a Bus from a Bundle is that it is indexed instead of having names for each position, the member Ports of a PortBus are also required to have names that are unique with respe ct to each other. This is because all PortBusses are PortBundles which have this constraint.
3.6.12 Entity: PortInst
TYPE 

  cfidrPortInstOwner = SELECT(cfidrInst,cfidrPortInstBundle);

END_TYPE;
ENTITY cfidrPortInst 

  ABSTRACT SUPERTYPE OF (ONEOF (

    (cfidrPortInstScalar, cfidrPortInstBundle))

  SUBTYPE OF (cfidrObject);



  Owner:        cfidrPortInstOwner;

  Describer:    cfidrPort;



DERIVE

  DescriberName:        cfidrStringT := Describer.Name;

END_ENTITY;
CONSTRAINT
An Inst has precisely one PortInst for each Port on the Describer NetlistView of the Inst. Each PortInst is of comparable sub-type to the corresponding Port: i.e., PortInstScalar for PortScalar, PortInstBundle for PortBundle, and PortInstBus for Po rtBus. Any PortInst substructure of bundles (or busses) must match the substructure of the Describer Ports.
3.6.13 Entity: PortInstScalar
ENTITY cfidrPortInstScalar 

  SUBTYPE OF (cfidrPortInst);
  SELF\cfidrPortInst.Describer: cfidrPortScalar;

  NetScalar: OPTIONAL cfidrNetScalar;



DERIVE

  DescriberDirection:   cfidrPortDirection :=

                                        Describer.Direction;

END_ENTITY;
CONSTRAINT
The Describer of the PortInstScalar must be a PortScalar.
3.6.14 Entity: PortInstBundle
ENTITY cfidrPortInstBundle 

  SUBTYPE OF (cfidrPortInst);



 SELF\cfidrPortInst.Describer: cfidrPortBundle;

 PortInsts:  LIST [0:?] OF UNIQUE cfidrPortInst;

 NetBundles:  SET [0:?] OF cfidrNetBundle;

END_ENTITY;
CONSTRAINT
The Describer of the PortInstBundle must be a PortBundle.
3.6.15 Entity: PortInstBus
ENTITY cfidrPortInstBus

  SUBTYPE OF (cfidrPortInstBundle);
DERIVE

  Start: cfidrInt32T := Describer.Start;;

  Step:  cfidrinst32T := Describer.Stop;

END_ENTITY;
CONSTRAINT
In spite of the fact that, for some systems, the distinguishing characteristic of a Bus from a Bundle is that it is indexed instead of having names for each position, the member PortInsts of a PortInstBus are also required to have names which are unique w ith respect to each other. This is because all PortInstBusses are PortInstBundles which have this constraint.

The Describer of the PortInstBus must be a PortBus.
3.6.16 Entity: Net
ENTITY cfidrNet

  SUBTYPE OF (cfidrNamedObject);

  ABSTRACT SUPERTYPE OF (ONEOF (

     (cfidrNetBundle, cfidrNetScalar));



  Owner:      cfidrNetlistView;

  Ports:      SET [0:?] OF cfidrPort;

  PortInsts:  SET [0:?] OF cfidrPortInst;

  NetBundles: SET [0:?] OF cfidrNetBundle;



WHERE

  SIZEOF(Ports) +  SIZEOF(PortInsts) >= 2;

END_ENTITY;
CONSTRAINT
Each net must connect at least two things---eventually.
3.6.17 Entity: NetScalar
ENTITY cfidrNetScalar

  SUBTYPE OF (cfidrNet);



  SELF\cfidrNet.Ports: SET [0:?] OF cfidrPortScalar;

  SELF\cfidrNet.PortInsts: SET [0:?] OF cfidrPortInstScalar;

  IsGlobal:      cfidrBooleanT;



END_ENTITY;
3.6.18 Entity: NetBundle
ENTITY cfidrNetBundle

  SUPERTYPE OF (cfidrNetBus)

  SUBTYPE OF (cfidrNet);



  SELF\cfidrNet.Ports: SET [0:?] OF cfidrPortBundle;

  SELF\cfidrNet.PortInsts SET [0:?] OF cfidrPortInstBundle;

  Nets: LIST [0:?] OF cfidrNet;

DERIVE

  Size: SIZE_OF(Nets);

END_ENTITY;
3.6.19 Entity: NetBus
ENTITY cfidrNetBus

  SUBTYPE OF (cfidrNetBundle);


  Start: cfidrInt32T;

  Step:  cfidrInt32T;

END_ENTITY;
CONSTRAINT
In spite of the fact that, for some systems, the distinguishing characteristic of a Bus from a Bundle is that it is indexed instead of having names for each position, the member Nets of a NetBus are also required to have names which are unique with respec t to all Net names in the Owner NetlistView. This is because NetBusses are NetBundles which are Nets which have this constraint.
Table of Contents Next Chapter