| Term |
Explanation |
| Bundle |
A class derived from TBundle or an instance of such a class.
Bundles are used to group ports. Bundles may be nested, i.e., bundles may contain other bundles.
The most important use of bundles is to specify the interfaces between subsystems.
Two bundles of the same type may be connected in a single operation, e.g.,
BundleA << BundleB;.
This statement is equivalent to connecting each port in BundleB to the corresponding port in BundleA.
A bundle is not a net or group of nets.
A bundle is analogous to a complex connector to which connections may be made.
|
| CAD Netlist |
A netlist used to transfer part and connection information to a PCB layout tool. |
| Connect |
To specify an electrical connection in a module's Connect() function.
Connect is also the name of one of the CBOLD passes.
|
| Designator |
Every registered module, part, bundle and port has a designator.
The designator consists of a name (a character string) and an optional number (an integer).
The number is typically used with arrays.
For example, a module might have an array member declared as CP_Cap_1uF Cap[ 3 ];.
The designators (name,number) for the elements of this array would be Cap,0; Cap,1; Cap,2.
For more, see TDesignator.
Designators are not to be confused with traditional reference designators, which appear in the CAD netlist.
|
| Designator Text File |
A text file that lists the symbolic path of some or all of the parts in the design along with each part's reference designator.
The file's format is described in the Reference Manual's Designator Text Files section. |
| Designer |
Same as user. |
| Example Design |
A complete CBOLD design provided as an example of reasonable CBOLD use, style, etc.
See the CBOLD Example Designs page.
|
| Global No-Connect |
A special global net named "/NC" to which the designer connects pins that will not be electrically connected on the PCB.
The no-connect net appears in the symbolic netlist, but it is not included in CAD netlists. |
| Module |
A class derived from TModule or an instance of such a class.
Modules are analogous to pages within a schematic.
Connections are made within the Connect() function of modules.
|
| Module/Part |
In many ways, modules and parts are similar.
When referring to an object that could be either a module or a part, the CBOLD documentation may use the term module/part or ModPar.
|
| Net |
The set of all pins attached to a single conductor.
See also the global no-connect net, which is used to identify all pins not connected to any other pins.
|
| Net List |
Same as netlist. |
| Netlist |
A file or object in memory that lists all nets in a design.
In addition to standard netlist formats needed by PCB layout tools, CBOLD can generate symbolic netlists.
Symbolic netlists are readable by humans.
The HTML version is also readily navigable with a web browser.
|
| Netlist Extraction |
The process of forming a TNetlist object in memory based on the database generated by the calls of Register() and Connect() functions.
CBOLD performs netlist extraction at the end of the Connect pass.
The TNetlist object is available to code in the PostConnect pass as well as postprocessing code.
For example, postprocessing code uses the TNetlist object to generate a netlist file suitable for import into a layout tool.
|
| Owner |
The module, part, or bundle that contains the registered member. For example, if Foo is a registered member of CM_Bar, then CM_Bar is the owner of Foo. See also: ultimate owner. |
| Part |
A class derived from TPart or an instance of such a class.
Parts represent physical components such as integrated circuits, resistors, etc.
Parts do not have internal connections or member parts or modules.
Parts typically do have member ports.
Bundles are not allowed to be members of parts in the present implementation of CBOLD.
|
| Part Text File |
Also known as part file or .pt file.
Part text files are plain text files that describe a physical component, such as an integrated circuit.
They are a concise listing of pinout, footprint, etc.
Part text files are converted to C++ header (.h) files by the pt_to_h Support Tool.
The user then #include's the .h files in his design.
|
| Pass |
A major division of standard CBOLD processing within main().
The standard passes are Register, AssignReferenceDesignators, Connect, and PostConnect.
Each pass operates on the entire design and completes in its entirety before the next pass starts.
Postprocessing is not considered a pass, because it is largely dependent on desired user output.
|
| Port |
A class derived from TPort or an instance of such a class.
Also, port is a typedef for TPort, i.e., it is a synonym.
Modules, parts and bundles may have member ports.
Ports provide the means for making connections between modules, parts and bundles.
The range of a port, e.g., 31 to 0 for a 32-wide port, is specified when the port is registered.
|
| Port Range |
A subset of a port.
For example, if P is a port, P(3,0) is a port range that represents the four least-significant bits of P.
Port ranges can be connected together using the CBOLD connection operators, for example, the statement DATA(7,0) << RAM.D; connects the entire range of RAM's D port to the eight least-significant bits of this module's port DATA.
|
| Postprocessing |
Any processing occuring after the final CBOLD pass.
Postprocessing code generates most output files, including netlists, bills of materials, etc.
Postprocessing functionality is determined by user code in main().
This allows each user to specify desired output files.
The CBOLD example designs illustrate practical user postprocessing code.
|
| Property |
An instance of a class derived from TProperty.
Properties are used to carry information to postprocessing code.
For, example, they can be used to identify nets that the layout tool should treat as differential pairs;
postprocessing code would use the properties to generate autorouter or layout rules files.
|
| Reference Designator |
A short string that usually consists of a few letters followed by a number and is used to identify parts in CAD netlists.
For example, U1 might be a reference designator for an integrated circuit, and R3 might be a reference designator for a resistor.
|
| Register |
To record information about a member with the CBOLD framework.
Typically recorded is the name of the member and, for bus ports, the range of the port, e.g., (31,0) for a 32-bit bus port.If a member is not registered, the CBOLD framework does not know it exists.
Register is also the name of one of the CBOLD passes.
|
| Root |
The module that is highest in the design hierarchy.
This module is typically declared as type CM_Root.
It is instantiated as Root.
|
| Subbus |
A fragment of a net or bus (i.e., set of nets).
A subbus is basically a list of port ranges all of which are to be connected together.
All of the port ranges in the list have the same width.
For example an eight-wide subbus might contain P(7,0) and D(31,24), but it could not contain A(15,0).
Subbusses are formed in the Connect() function of modules.
During netlist extraction, CBOLD processes all subbusses in the design to form the final netlist.
|
| Subsystem |
A module that is at the second-highest level of the design hierarchy. I.e., a module instantiated in CM_Root. |
| Support Tool |
Any program that is not compiled/linked with a CBOLD design but assists the designer in developing, viewing, or analyzing a CBOLD design. |
| Symbolic Name |
The name assigned to a member during the Register pass.
This name is the same as the member's instance name, assuming that one of the CBOLD registering macros is used to register the member.
Every registered module, part, bundle and port in a CBOLD design has a symbolic name.
The names are usually chosen to convey important information.
For example, a resistor might be named Pullup, Sterm, or Pterm, depending on whether it is functioning as a pullup resistor, a series terminator or a parallel terminator.
|
| Symbolic Path |
The ordered list of symbolic names that uniquely identify a member within the design hierarchy.
The symbolic path consists of the member's symbolic name preceded by the symbolic name of each owner up to but typically excluding Root, with each name separated by a dot.
For example Foo.Bar.Buffer.VCC is the symbolic path to the VCC port of instance Buffer (e.g., of class CP_SN74ABT245) within the Bar module within the Foo module.
|
| Ultimate Owner |
If a member's owner is not descended from TBundle, then its ultimate owner is its owner.
Otherwise, its ultimate owner is its owner's ultimate owner.
I.e., a member's ultimate owner is found by ascending the owner hierarchy until an owner is found that is not a TBundle.
|
| User |
The person who is writing source code that utilizes the CBOLD framework. |
| Term |
Explanation |
| Class |
A user-defined type. New classes can be declared using either class or struct. |
| Derive |
To define a new class based on an existing class. |
| Exception |
An object that is thrown via the throw keyword.
CBOLD uses exceptions to report errors.
|
| Header file |
A file that is included in a C++ source file via the #include preprocessor directive.
User header files usually have extension .h or .hpp.
|
| Include path |
A list of directories to be searched by the C++ compiler when looking for header files, i.e.,
files included with #include.
The include path allows C++ source files to include files without specifying their complete location within the file system.
|
| Instance |
A variable of a class type.
For example, if TColor is a class. Then TColor Background; declares an instance of TColor called Background.
The class TColor has no memory associated with it, whereas each instance of Background has its own memory to hold the class's member variables, e.g. one byte for each of Red, Green, and Blue.
|
| Instantiate |
To declare an instance of a class. |
| Member |
A variable or function declared within a class.
See also Method. |
| Method |
A synonym for member function.
|
| Object |
Same as instance. |
| Overload |
To reuse a function name but with different arguments.
In C++, it is legal to declare multiple functions all having the same name as long as the argument lists are different.
For example, it is legal to declare both double Area( TCircle C ); and double Area( TRectangle R );.
If you call Area() with argument S, the compiler will choose the function to call based on whether S has type TCircle or TRectangle.
Because operators, such as +, -, and << are just functions, it is also possible to overload operators.
For example, the CBOLD framework overloads operator<<() to allow several different types of connections. |
| Polymorphic |
Having more than one form.
In C++, a class having at least one virtual function is polymorphic.
See virtual function.
|
| RTTI |
Runtime Type Information.
A feature of C++ that allows code to obtain information about an object or class.
For example, given a pointer to an instance of a polymorphic class, RTTI can provide a string containing the name of the instance's type.
|
| Runtime Error |
An error that occurs when a program is running.
In contrast, compile-time errors occur before a program is run, i.e., during compiling or linking.
Runtime errors detected by the CBOLD framework result in an informative error message
as described in the Error Handling section of the CBOLD Reference Manual.
|
| this |
Every instance of a C++ class can be thought of as having a pointer to itself called "this". Within a class's member functions, "this" means "the current instance of the class" or "the instance of the class to be operated upon". |
| Type |
C++ is a strongly typed language. This means that every name has an associated type that is known at compile time.
C++ features built-in types, such as int and double.
Classes are user-defined types. |
| Virtual Function |
A member function declared with the virtual keyword.
Virtual functions are called through a virtual table, which is indexed according to object type.
For example, the function Connect() is a virtual member function of CBOLD's TModule class.
The user derives new classes from TModule and specifies connections in the Connect() of each new class.
During the Connect pass, the CBOLD framework uses a pointer to each registered module to call the module's Connect().
The pointer is a pointer to TModule, but, because Connect() is virtual, the call is performed via a virtual table.
The actual Connect() function called is the Connect() function of the descendant class.
|
