4. CCI architecture overview

The core of the SystemC Configuration standard is the pairing of parameters and brokers, where a parameter is a named instance of a specific compile-time type and a broker aggregates parameters and provides access to them in the form of handles. Brokers and parameters are both generally accessed via handles which, among other things, identify the source (“originator”) of new parameter value assignments. Originator identification is commonly contextual and managed implicitly.

Each parameter is registered during construction with a single broker. Parameters are typically constructed and owned by a SystemC module, with other users subsequently obtaining a handle from the broker. The owner constructs a parameter with a default value, however the broker can override this with a preset value, allowing tools to provide runtime configurations.

Typically a global broker will exist, created early in the elaboration phase. Modules may supply their own local brokers, for example to keep their parameters private. In such a case, a hierarchy of brokers mirrors the hierarchy of sc_modules.

Figure 1 shows a typical sequence of a parameter being constructed and used:

1. A tool obtains a broker handle (cci_broker_handle, not explicitly shown) and specifies a preset value for the named parameter (cci_param); this should be completed prior to construction of the owning module.
2. The module owning the parameter instantiates it with a default value.
3. The parameter registers with the broker (cci_broker_if) and acquires the preset value, supplanting the default.
4. A user gets a handle for the parameter (cci_param_handle) and through it gets the current (i.e. preset) value.

Figure 1Key interactions for parameter construction and access

It is useful to consider several perspectives when overviewing the more complete set of SystemC Configuration standard features:

• Tools
  Tools access brokers and parameters via handles and facilitate parameter interaction. A variant type is provided for exchangingparameter values in a highly portable manner referred to as “untyped access” as depicted in Figure 1. Tools will also expose parameter attributes provided at construction (see Parameter creation and direct access below) as well as the origin of the current value and any metadata. Tools may utilize broker callbacks and parameter callbacks to report or respond to interesting events.
• Parameter creation and direct access
  Modules containing parameters will specify their compile-time type, description, and default value. They may provide additional metadata for the benefit of tools, users, and possibly other code. They can use parameter callbacks for reacting to parameter accesses. Ownership affords interacting with parameters directly, without handles.
• Parameter lookup and access via a handle
  SystemC code outside of the owning module will request a broker handle and in turn perform a name based lookup to obtain a parameter handle. With a few exceptions, such as inability to reset the parameter or override the parameter’s description and metadata, the handle provides an interface equivalent to the parameter itself. A testbench is one example of this perspective.
• (Sub-)System packaging and integration
  Local brokers are introduced at the time of packaging and/or integration to impose policies such as parameter hiding.
• Infrastructure
  Developers of modeling infrastructure will be concerned with enabling user-defined parameter value types and adapting legacy parameter implementations for conformance with the standard.