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

14. Outputs

Under Construction

CBOLD generates a variety of output, from simple status messages to complex netlist files. CBOLD includes much output functionality, and the user is free to add more.

Section Contents

14.1. Symbolic Names and Paths

Symbolic names and symbolic paths appear in many forms of output. A symbolic name is a name the designer assigns to an instance of a module, part, bundle or port. The assignment is made in a module's Register() function. If the instance is an element of an array, the symbolic name will end with the index of the element as assigned in Register(). (More accurately, if the instance was assigned a number during registration, that number will appear at the end of the symbolic name.) For example:

class CM_RegisterFile : public TModule {  // a module to encapsulate a register file
public:
  port VCC;    // 3.3V supply
  port GND;
  port D;
  port Q;
  port STB;       // one rising–edge clock for each register, connected to register's CLK pin
  port OE_N;      // one output enable for each register
 
  ...
  CP_SN74LVTH574 Registers[ 4 ];   // four 8–bit flip–flop chips
 
  virtual void Register() {        // symbolic names:
    reg(  VCC );                   //   VCC
    reg(  GND );                   //   GND
    regb( D, 7, 0 );               //   D
    regb( Q, 7, 0 );               //   Q
    reg(  STB,  3, 0 );            //   STB
    regb( OE_N, 3, 0 );            //   OE_N
    rega( Registers, 4 );          //   Register3, Register2, Register1, Register0
  }
 
  virtual void Connect() { ... }
 
};

A symbolic path is a symbolic name preceded by the symbolic names of containing modules. Each level of the hierarchy is separated by a period. The highest level of the hierarchy (typically Root) is omitted. For example:

class CM_Root : public TModule {   // the highest level module of a design
public:
  ...
  CM_RegisterFile  RegisterFileA;   // member modules
  CM_RegisterFile  RegisterFileB;
 
  virtual void Register() {
    reg( RegisterFileA );
    reg( RegisterFileB );
  }
 
  virtual void Connect() { ... }
 
};

The symbolic path for the VCC port of RegisterFileA is: RegisterFileA.VCC The symbolic path for the first element of the Registers array of RegisterFileB is: RegisterFileB.Registers0 The symbolic path for the clock port of the second element of the Registers array of RegisterFileB is: RegisterFileB.Registers1.CLK

Though symbolic paths look similar to C++ expressions, they are not intended to be used in design source code. They are a convenient notation for identify modules, parts, ports, etc. in some files output by CBOLD. For example, see the discussion of symbolic netlists, below.

14.2. Status and Error Messages

CBOLD contains a common mechanism for reporting errors to the user. This mechanism, implemented with the BEGERR/ENDERR macros, allows CBOLD to throw error exceptions that contain debugging information.

CBOLD attempts to provide all pertinent information when an error is detected. In some cases, however, symbolic information will not yet be available, because the offending instance has not yet been registered. Because the Register pass is the first pass, however, a symbolic name is typically available. Lack of a symbolic name is typically an indication that a module, part, bundle or port was not registered by the designer.

Errors are fatal. The designer must correct the error before the design's main() will fully execute.

Though it is seldom necessary to do so, the designer is free to use the CBOLD error reporting mechanism to report his own errors. Examples of BEGERR/ENDERR use can be found in the CBOLD source code.

For more on error messages and debugging, see Tips and Tricks.

14.3. Symbolic Netlist

The symbolic netlist contains all nets, including the no–connect net.

14.4. CAD Netlist

The CAD Netlist contains all nets except the no–connect net.

14.5. Autorouter Command Files

Autorouter command files are an advanced feature. Custom post-processing code is typically required. TGenLayoutScript, in the IROD example design, is an example of a custom class that creates .do files for the SPECCTRA® autorouter. The .do files instruct the autorouter to match clock line lengths, etc. Creating such files manually would be extremely tedious.

The IROD example design uses TGenLayoutScript in conjunction with the CR_MatchClock property to create several .do files. See CBOLD Example Designs.

14.6. ASIC Constraint Files

CBOLD can automatically generate meaningful constraint files for FPGA's and PLD's. CBOLD builds a constraint file based on the port names of the programmable device's wrapper module, generating a constraint file that matches the device's connections within the design.

The TXConstraints class implements customizable constraint file generation. The class is documented in cb_xconstraints.h, included in the CBOLD distribution.

For an example of TXConstraints use, see irod.cpp from the IROD example design.

For example constraint files, see the IROD example design's output directory.

14.7. Bill of Materials

CBOLD generates a simple bill of materials suitable for importing into a spreadsheet. For examples, see the files named *bom.txt in the output directories of the CBOLD Example Designs.

14.8. Why does CBOLD Lack an Electrical Rules Checker?

CBOLD is concerned with connectivity and reports potential connectivity mistakes, e.g., unconnected pins not in the global no–connect net. It also enforces connectivity rules, e.g., by reporting errors when the designer attempts to connect port ranges with different widths.

CBOLD does not contain a traditional electrical rules checker. For example, CBOLD will not report that an output pin is connected to VCC.

The primary motivation for not including an electrical rules checker in CBOLD is that such mechanisms tend to be more of an encumbrance than an aid to the experienced designer. To use a sophisticated design rules checker, the designer (or part librarian) must provide detailed information about each pin of a part: type (INPUT/OUTPUT/OC/PASSIVE/POWER, etc.), drive strength, I/O standard, load, etc. Often it is difficult to classify a pin, and the designer resorts to classifying pins as PASSIVE. An additional burden would be the specifying the direction of each port of each module.

An experienced designer is unlikely to make the sort of connection or loading errors that the design rules checker is meant to identify, and, in any case, an electrical rules checker is incapable of analyzing the more pressing concern of the designer: signal integrity. Furthermore, the proliferation of programmable logic, especially FPGA's, means the operating characteristics of most pins may be unknown at the time of board–level design or even variable over the life of the PCB.