C++ Design Capture
CBOLD designs are captured in C++.
C++ is a universally established programming language with excellent development tools, including free compilers.
CBOLD users can develop their designs in a mainstream C++ environment, rather than within the confines of a niche market sector product.
This allows for higher quality development environments at a lower cost.
C++ is a much more stable development medium than any schematic capture application,
so user design files are unlikely to be rendered obsolete.
Every part and module in a CBOLD design has a symbolic path.
These paths help the designer rapidly identify a part's place within the design's hierarchy.
CBOLD can generate symbolic netlists, both in plain text and hyperlinked HTML.
A symbolic netlist contains not only physical information (such as reference designators and pin numbers)
but also symbolic information such as pin name, part type, and part symbolic path.
Symbolic netlists are more readily navigable than paper schematics, and they can be published on the World Wide Web.
Hierarchical Reference Designators
CBOLD supports hierarchical reference designators.
By default, CBOLD reference designators are assigned in the same way as reference designators are assigned by traditional design capture tools.
But the user may also assign reference bases to modules.
For example, if a design has two identical Audio modules,
the designer might assign the right Audio module a base of AR and the left Audio module a base of AL.
CBOLD would then assign these modules reference designators that looked like ARU1, ARU2, ..., and ALU1, ALU2, ....
For large designs and those with replicated modules, the systematic reference designators can be an aid during layout and debugging.
CBOLD bundles allow the designer to group and nest ports. For example, a JTAG bundle could contain ports TDI, TDO and TCK.
Bundles can be connected in a single statement, for example:
Bundles are particularly useful for defining the interfaces between subsystems.
Emulator.JTAG << Processor.JTAG;
Constraint file (UCF) output
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.
Here is an example CBOLD-generated constraint file for a VME slave controller PLD.
CBOLD allows the designer to declare arrays of parts, ports, and modules.
Most modules in a CBOLD design are static, just as schematic pages are static.
But CBOLD also allows the designer to create dynamic modules whose members (e.g., parts and modules) and internal connections are
determined at run time by C++ code.
For example, the many complex features of some modern FPGA's lead to board-level implications.
Rather than burden the high-level designer with these details, an intelligent FPGA wrapper module can encapsulate them.
For example, several Xilinx® FPGA's feature Digitally Controlled Impedance, or DCI.
If DCI is used for a particular I/O bank, two of that bank's I/O pins must be connected to supply voltages through resistors.
If DCI is not used for a bank, then the two I/O pins are available as general-purpose I/O and the resistors are not needed.
A wrapper module for such an FPGA can have a method, e.g.,
UseDCI( bank#, ... ) that the user calls to tell the module which banks will be using DCI.
If the user called the method like this:
MyFpga.UseDCI( 0, 1, 6, 7 );
then the FPGA module would instantiate and connect the necessary resistors for banks 0, 1, 6, and 7 and remove the corresponding eight DCI pins from the I/O pool.
The CBOLD framework is distributed as C++ source code.
It is easy to extend, either by deriving new classes from existing CBOLD classes or by creating entirely new functionality.
In particular, the user is free to create any desired postprocessing functionality.
The CBOLD framework is free software.
Using free software is convenient and inexpensive.
There are no hassles with awkward licensing mechanisms.
The user can modify or augment free software as desired (in accordance with license terms).
A CBOLD design is composed entirely of plain text.
Plain text has many virtues. It is easily viewed and manipulated with your favorite editor. It is unlikely to ever become obsolete.
CBOLD can naturally reflect the order of a design
CBOLD designs are not constrained by the size or shape of a schematic page.
There is no need to break FPGA's and other high-pinout parts into smaller blocks just so they will fit on a page.
A CBOLD module can contain as few or as many components as desired.
Arrays of parts or modules are natural in a CBOLD design, as is
CBOLD postprocessing is fully automated. Complete output is generated every time the design is executed.
CBOLD properties help bridge the divide between design entry and layout tools by supporting custom postprocessing functionality.