| CAct | The main Act class used to read in an ACT file and create basic data structures. All design information can be accessed through this data structure |
| Cact_attr | Attribute list associated with an instance |
| Cact_boolean_netlist_t | This structure is computed for each process by the Booleanize pass. It summarizes the information about all the variables in the design, capturing basic information for all the language bodies |
| Cact_booleanized_var | The core data type for a variable accessed in an ACT process. A variable may be an act_booleanized_var or an act_dynamic_var. The latter is used for dynamic array references, and the act_booleanized_var structure is used for all other variables |
| Cact_chp | Holds a CHP sub-language |
| Cact_chp_gc | Data structure for guarded commands |
| Cact_chp_lang | Data structure for the chp sub-language body |
| Cact_connection | Connections |
| Cact_dataflow | The dataflow sub-language |
| Cact_dataflow_element | An individual dataflow element |
| Cact_dataflow_order | An order directive in the dataflow language, used for optimizations in the presence of hierarchy |
| Cact_dynamic_var | CHP programs can have complex dynamic accesses, with runtime array references. The Booleanize pass records these as "dynamic
variables" represented by this structure |
| Cact_func_arguments | Used to represent log(...) arguments. Holds either a string or an expression |
| Cact_initialize | The Initialize { ... } body. Only used in the global namespace |
| Cact_languages | This holds all the sub-langugae bodies in a namespace/user-defined type definition |
| Cact_local_net_t | This is used for flat netlist generation to represent a net that consists of a net name and a list of pins |
| Cact_local_pin_t | This is used for flat netlist generation to represent an I/O pin for a leaf cell |
| Cact_nl_varinfo | |
| Cact_prs | Structure that holds all the prs { } blocks in a particular scope. This is a linked-list of blocks, each of which can have their own voltage domain specification |
| Cact_prs_expr | A production rule expression, corresponding to the guard for the production rule |
| Cact_prs_lang | Structure that holds a prs sub-language body. This consists of a linked-list of individual items in the prs body |
| Cact_refine | The refinement sub-language just contains an ActBody |
| Cact_size_spec_t | Sizing specifier for variables |
| Cact_sizing | The sizing { ... } body data |
| Cact_sizing_directive | An individual sizing directive |
| Cact_spec | The specification sub-language |
| CActApplyPass | |
| CActBody | This class is used to hold the contents of the body of any user-defined type or namespace. This is the data structure created during parsing, and stored in the unexpanded versions of namespaces and user-defined types |
| CActBody_Assertion | This is used to store assertions in the body. There are two types of assertions: |
| CActBody_Attribute | This is used to record attributes associated with an instance name |
| CActBody_Conn | This is used to record a connection in the input design file |
| CActBody_Genloop | This is used to contain a generalized loop in the ACT body |
| CActBody_Inst | This class is used to hold information about an instance in the body of a namespace and/or user-defined type |
| CActBody_Lang | This is a language body |
| CActBody_Loop | This holds information about loops that has to be unrolled. Loops can be of different types |
| CActBody_Namespace | This is used to switch namespaces during the expansion phase |
| CActBody_OverrideAssertion | This is added for override checks that can be completed only during the expansion phase. The added complexity is that overrides may depend on the identifier being created (it may be conditionally created, for example). The name_check field is used to check that the identifier in fact exists before testing for overrides |
| CActBody_Print | This is used to display messages during expansion |
| CActBody_Select | This is used to contain the complete selection statement in the core ACT language |
| CActBody_Select_gc | This is used to represent the list of guards and statements for conditional circuit construction |
| CActBooleanizePass | This pass is used to pre-process information about languages and variables within the design. The pass computes the act_boolean_netlist_t data structure, which contains information about all the local variables used by the process |
| CActCellPass | |
| CActCHPArbiter | |
| CActCHPFuncInline | |
| ►CActCHPMemory | |
| Cmemvar_info | |
| CActConniter | This is an iterator that, when passed an act_connection pointer, allows you to iterate through all the connections made to this particular connection pointer |
| ►CActDynamicPass | This is an ActPass that is dynamically loaded in at run-time via a shared object library. A dynamic pass can be used to extend the Act framework at run-time without having to re-compile/statically link in new functionality. Apart from loading in new passes in at runtime via C++, the interact command-line interface to the Act system also supports loading in new passes at runtime |
| Cact_sh_dispatch_table | These are the C function pointers extracted from the shared library used to execute the various methods in the ActDynamicPass |
| Cact_sh_passlib_info | This holds information about the shared object file |
| CActId | This class is used to store Act identifiers that correspond to instances. Identifiers have an optional namespace prefix (in the case of namespace global identifiers), followed by a list of components of the idenfier |
| CActInstiter | This is an iterator that, when passed a Scope pointer, allows you to iterate through all instances within the Scope. Note that if two instances are connected to each other, they will both be visited by the iterator |
| CActNamespace | Holds all the information about a namespace |
| CActNamespaceiter | This is an iterator that, when passed an ActNamespace pointer, allows you to iterate through nested namespaces within the specified namespace |
| CActNetlistPass | |
| CActOpen | Functions to manage namespace search paths |
| CActPass | The main ActPass class used to implement an ACT analysis/synthesis pass. All the core tools use this framework to operate on the ACT data structures. Passes are called once the design has been expanded |
| CActSizingPass | |
| CActStatePass | |
| CActTypeiter | This is an iterator that, when passed an ActNamespace pointer, allows you to iterate through all user-defined types that were defined within the namespace |
| CActUniqProcInstiter | This is an iterator that, when passed a Scope pointer, allows you to iterate through all the uinque process instances within the scope |
| CAExpr | Array expressions |
| CAExprstep | Class for stepping through an array expression element-by-element |
| ►CArray | Dense arrays, sparse arrays, and array dereferences |
| C_act_array_expr_pair | A range specifier that can include parameters/etc. This is used during parsing, prior to expansion |
| C_act_array_exprex_pair | A range specifier post expansion where all parameters/etc. are substituted, resulting in a constant range |
| C_act_array_internal | Used to hold the result of an expanded array range reference |
| Crange | |
| CArraystep | Class for stepping through an array |
| CBool | Used to represent the built-in ACT bool datatype |
| CChan | Used to represent the built-in ACT Paramterized chan(foo) type or chan(foo,foo) bi-directional/exchange channel |
| CChannel | User-defined channel type. Channels can be unidirectional or bi-directional (sometimes called exchange channels) |
| CContact | Used to represent a contact between two routing layers (adjacent) or between a material and the first routing layer for it |
| CData | A user-defined data types |
| CDiffMat | Used to hold rules for diffusion |
| Cedge | |
| Cexpr | |
| CExternMacro | This is used to record information about a macro from an ACT configuration file |
| CFetMat | Used for transistors |
| CFunction | This holds information about ACT functions. ACT functions are of two types: |
| CGDSLayer | Holds information about a GDS layer. Any Material will have a footprint on a single or multiple GDS layers. These layers are specified in the layout configuration file (layout.conf). More details on this are available at https://avlsi.csl.yale.edu/act/doku.php?id=config:layout |
| Cidmap | |
| Cinst_param | This holds a single template parameter. A template parameter is either an array expression, or an InstType |
| CInstType | An instance type |
| CInt | Used to represent the built-in ACT int< > datatype. This is also used to represent enumerations |
| CInterface | Holds the interface definition. Looks like a process. Body is empty |
| CMaterial | Used to hold information about a material. Materials correspond to abstract geometry, and get mapped to one or more GDS layers. More details are avaiable at: https://avlsi.csl.yale.edu/act/doku.php?id=config:layout |
| Cnetlist_bool_port | This holds information about a port in the Booleanized netlist data structure |
| Cnetlist_capacitor | |
| Cnetlist_global_port | This is used to hold information about a global signal used in a process |
| Cnetlist_t | |
| Cnode | |
| CPBool | Used for Boolean parameters |
| CPInt | Integer parameter type |
| CPInts | Unused. Originally pint and pints were supposed to be unsigned and signed integers. Now pint is a signed integer |
| CPolyMat | This is for polysilicon, which is a special routing material with more issues |
| CPReal | Used for real parameters |
| CProcess | User-defined processes |
| CPType | Used for ptype( ) parameters. ptype parameters take an interface type as a template parameter |
| CRangeTable | A range table is a table of values that are indexed by ranges. It can be viewed as a map from contiguous ranges [a,b] to v |
| CRoutingMat | Used to hold routing materials with extra routing design rules |
| CRoutingRules | Holds design rules for all routing materials (metals, poly) |
| CScope | This is the data structure that holds all instances and their associated types within a scope. Each user-defined type has an associated Scope, and so does each ActNamespace |
| Cstate_counts | |
| Cstateinfo_t | |
| CTechnology | This holds all the technology design rules (or at least the approximate ones) used by the ACT library and tools. This is sufficient to generate the technology LEF used for routing. There can only be one Technology allocated. This information is loaded from the layout.conf ACT configuration file |
| CType | The abstract base class for all types in the system |
| CTypeFactory | This is the class used to create all instance types. It also caches types to reduce memory usage |
| CUserDef | UserDef stores information that is common to all user-defined types. User-defined types are more complex, because they can have definitions and template parameters. To handle this complexity and to reduce storage requirements, the "shared" part of a user-defined type is factored out into this class. That way the body of a channel x1of2 is shared with x1of2? and x1of2!, as well as an array of x1of2 (for example) |
| CUserMacro | Used to hold a user-defined macro. These macros provide more convenient methods to interface with processes and data types |
| CValueIdx | This class is used to create an instance in a scope. The name comes from the fact that this is used to keep track of the index of a value within a particular type (rather than a flat data structure, one per instance) and so is not defined as a value-per-instance, but rather a value-per-type |
| CWellMat | Used for wells |
