Primitive Components

Primitive components are the basic building block elements whose energy and area estimates can be directly cpatured by Accelergy's plug-ins. Therefore they are referenced as Accelergy's backend library instead of an input to each Accelergy evaluation.

The complete set of default primitive components classes are installed together with Accelergy source code, example path /home/usr/local/share/accelergy/primitive_component_libs/. They can also be found here. For most cases, primitive components do not need to be updated.

The version key

Each top-level YAML key used as a Timeloop/Accelergy input has a version. The current version for the archtecture: is 0.3, which is specified as follows:

primitive_components:
  version: 0.3
  ...

The classes key

Describes various compound component classes as a list. Each component component class has the following keys:

• name: the name of the class.
• attributes: the important hardware properties associated with the class.
• actions: runtime behaviors associated with the class.

The name key

Each component class is associated with a name.

primitive_components:
version: 0.3
classes:
  - name: intadder
  ...

The attributes key

Describes the high-level attributes associated with primitive component. Attribute name and its default value form key-value pairs. Please note that the user-defined attribute values in architecture specification can override the default vlaues stored in the library.

For example, an interger adder, intadder component needs has attributes technology, datawidth, and 'num_pipeline_stages`.

primitive_components:
version: 0.3
classes:
  - name: intadder
    attributes:
      technology: 45nm
      datawidth: 16
      num_pipeline_stages: 1
  ...

The actions key

Describes the different runtime behaviors the component can have, and each runtime behavoir is called an action associated with the component.

For example, an adder is either computing, resulting in an add action, or staying idle, resulting in an idle action.

primitive_components:
version: 0.3
classes:
 - name: intadder
    attributes:
      technology: 65nm
      datawidth: 16
      num_pipeline_stages: 1
    actions:
      - name: add
      - name: idle

The arguments in action specifications

Each action can also have its assocaited arguments, specified with the arguments key.

Each argument is described as a key-value pair: a user-defined argument name as the key, and a range of possible argument values as the value.

We use a register file component as an example. For each action, either read or write, there are two arguments associated with the action, named data_delta and address_delta. data_delta refers to the amount of changes in data values (thus bit flips) across consecutive cycles. The larger the delta, the more switching happens in the circuit, leading to a larger energy consumption. Similarly, address_delta refers the amount of swithcing happens at the addressing wires.

We use .. to indicate an inclusive range of the allowed argument values, e.g., data_delta: 0..1 refers to a min variation rate of 0 (i.e., data bits never change across consecutive cycles) and a max variation rate of 1 (i.e., data bits always flip across consecutive cycles).

primitive_components:
version: 0.3
classes:
 - name: regfile
    attributes:
      ...
    actions:
      - name: read
        arguments:
          data_delta: 0..1
          address_delta: 0..1
      - name: write
        arguments:
          data_delta: 0..1
          address_delta: 0..1
      - name: idle

accessibility