Coolquest, Inc.	Home	Products	Support	About	Contact
C++BOLD Reference Manual

9. Properties

9.1. Overview

A property class is a class derived from TProperty. A property is an instance of a property class. Properties have little effect except to carry information to postprocessing code. Their use is optional.

9.2. How do Properties Carry Information?

Properties carry information in several ways:

Thus (1) a design may have several properties, (2) each property may be associated with one or more objects, and (3) the designer may customize (i.e., set the values of members in) each property.

Properties can be associated only with objects of type:

Each property class can further restrict the associations it allows, throwing an exception when the designer attempts to associate a property with an object with which it is not compatible.

A single property instance can be associated with multiple CBOLD objects.

Properties must be persistent. I.e., they should be created with the C++ new operator and never deleted. When a property is created, it automatically adds itself to the property list in the design's root module. CBOLD provides the property() macro as a shorthand for creating property instances. From cb_prop.h:

#define property( atype, aref ) atype& aref = *(new atype)

For example, property( P_TraceWidth, Width1 ); creates a property of type P_TraceWidth and creates a reference to it called Width1. Width1 can be associated with objects of appropriate type, e.g., subbusses.

Properties can be used by post-processing code, e.g., to create layout script files. For example, the designer might associate a property with a port to indicate that nets connected to the port should be routed with traces not exceeding a specified length. Assuming that an appropriate property class did not yet exist, the designer would derive such a class as follows:

class P_MaxTraceLength : public TProperty {  // property for limiting trace length
  int MaxLength;   // max length in mils
 ...
};

Such a definition would typically appear in a header file dedicated to properties.

The designer associates instances of P_MaxTraceLength in a module's Connect() as shown below. The <= operator is used to make the associations.

#include "my_properties.h"          // for P_MaxTraceLength
...
class CM_Clocks : public TModule {  // module that generates three clocks
public:
  ...
  port CLK_40;                      // clock outputs
  port CLK_50;
  port CLK_100;
  ...
 
public:
  ...
  virtual void Connect() {
    ...
    property(P_MaxTraceLength, Max_LF );  Max_LF.MaxLength = 6000;  // 6 inch max
    property(P_MaxTraceLength, Max_HF );  Max_HF.MaxLength = 3000;  // 3 inch max
 
    Max_LF <= CLK_40 <= CLK_50;     // associate Max_LF with the two low freq. clocks
    Max_HF <= CLK_100;              // associate Max_HF with the high freq. clock
  }
};

Creating and associating these properties has no effect on the design, except to make the properties available to postprocessing code.

The IROD example design uses such postprocessing code to generate autorouter control (.do) files. See file irodprop.h. Approximately 40 kbytes of control files needed to match trace lengths, constrain far-end clusters, etc., were automatically generated by these calls in IROD's main():

Log << "Creating layout script files";    // output script (.do) files
TGenLayoutScript LayoutScript;
LayoutScript.GenerateScriptFile( &Root, &NetList );

The IROD designer coded the postprocessing class TGenLayoutScript and the property class P_MatchClock. Generating the control files algorithmically reduces tedium, reduces the chances of error, and eliminates labor due to design changes. Furthermore, much of the code is suitable for reuse in other designs.

Examples of some possible applications for properties are shown in the table below: