Components

Accelergy allows users to specify high-level function units as compound components. Compound components consist of several subcomponents, which can be either primitive components or compound components. Describing designs in terms of compound components simplifies runtime statistics generation, produces succinct design description, and reduces energy estimation errors caused by overlooking some primitive components.

For example, smartbuffer is a popular high-level function unit for accelerator designs with deterministic data movment behaviors. smartbuffer consists of a counter unit that generates the predetermined storage access patterns and a SRAM for data stroage. We will use the smartbuffer component as our running example in this section.

Different types of compound components are specified as compound component classes, each of which contains a fixed set of parameterizable attributes, description of its suncomponents, and definition of its actions. Each compound component is an instance of the compound component class with its unique sets of attributes. Components are instantiated in the architecture specification.

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:

compound_components:
  version: 0.4
  ...

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.
  • subcomponents: lower level components that this high-level function unit consists of.
  • actions: runtime behaviors associated with the class.
compound_components:
   ...
  classes:
     ...

The name key

Each component class is associated with a name. 

compound_components:
   ...
  classes:
     - name: smartbuffer

The attributes key

Describes the high-level attributes associated with the compound component class. Attribute name and its default value form key-value pairs. The special must_specify keyword indicates that there is no default value for the attribute and the user must provide one when instantiate a component.

For example, some important high-level attributes of a smartbuffer include the depth, width, and n_banks of the storage and the width of the counter unit, where the depth and width must be specified, n_banks has a default value and the address generator's width is derivable based on the required attributes.

compound_components:
classes:
- name: smartbuffer
  attributes:
    technology: must_specify
    memory_depth: must_specify
    memory_width: must_specify
    storage_n_banks: 1
    gen_width: log(memory_depth)
  ...

The subcomponents key

Describes a list of the lower-level components of a compound component. The lower-level component can either be a primitive component or another compound component. If latter, Accelergy's internal analysis is able to recursively define the subcomponent. As a result, we only need to define the current compound component class in terms of its most immediate subcomponents.

Please note that each subcomponent is also defined with its own class and attributes keys. Furthermore, the attributes of the subcomponent need to be defined in terms of the top-level attribute of the compound component class. It could be either a direct mapping, or some arithmetic operations with operators including +, -, *, log. 

compound_components:
  version: 0.4
  classes:
  - name: smartbuffer
    attributes:
      ...
    subcomponents:
    - name: storage
      class: SRAM
      attributes: 
        technology: technology
        depth: memory_depth
        width: memory_width
        gen_width: log(memory_depth)
        ...
    - name: address_generator
      class: inadder
      attributes:
        technology: technology
        datawidth: gen_width
        ...

The actions key

Describes the different runtime behaviors the component can have, and each runtime behavoir is called an action associated with the component. Often, an action of the compound componet is composed of multiple actions from its subcomponents.

For example, when data is read from a smartbuffer, the address_generator performs a add action to generate the read address and the buffer subcomponent perfroms a read action. ``` yaml
compound_components: version: 0.4 classes:

  • name: smartbuffer attributes: ... subcomponents: ... actions:
  • name: read subcomponents:
    • name: storage actions:
      • name: read
    • name: address_generators actions:
      • name: add ...

Just like primitive components, compound components can also have actions with arguments. To define them, we simply map the compound action's argument to subcomponent's action arguments:

compound_components:
classes:
- name: smartbuffer
  attributes:
    ...
  subcomponents:
      ...
  actions:     
  - name: read
    arguments:
      data_delta: 0..1
      address_delta: 0..n_banks
    subcomponents:
      - name: storage
        actions:
          - name: read
            arguments:
              data_delta: data_delta
              address_delta: address_delta
      - name: address_generators
        actions:
          - name: add
      ...

To be instantiated in the architecture, the following actions are required for each compound component:

  • read: Read data from the component. If the "read" action does not make sense for the component, the read action is the canonical action of the component, (e.g., "read" for an adder means to add).
  • write: Write data to the component. If the "write" action does not make sense for the component, the write action should have no subcomponents (i.e., be a no-op).
  • update: Write back a piece of data immediately after it has been read. If the "update" action does not make sense for the component, the update action should have no subcomponents (i.e., be a no-op).
  • leak: This action should take as an argument global_cycle_seconds and return a leakage energy per cycle (leakage power multiplied by global_cycle_seconds).

Estimating Using Plug-Ins

Accelergy uses plug-ins to estimate the energy and area of components. Given a primitive component with attributes, actions, and action arguments, Accelergy queries each of its plug-ins to find the one that will have the highest accuracy.

There are two special keys that can be used to specify the minimum accuracy and the plug-in to be used for the component. If not specified, Accelergy will pick the highest-accuracy plug-in available for a component. These attributes are to be set in the attributes of a primitive component.

compound_components:
  version: 0.4
  classes:
  - name: smartbuffer
    attributes:
      ...
      minimum_accuracy: 70 # Scale of 0 to 100
      plug_in: "pick_me_as_a_plug_in"
    ...

Special Attributes

The following are special attributes.

  • minimum_accuracy: The minimum accuracy of the plug-in to be used for the component. The accuracy is a scale of 0 to 100. If not specified, Accelergy will pick the highest-accuracy plug-in available for a component.
  • plug_in: The name of the plug-in to be used for the component. If not specified, Accelergy will pick the highest-accuracy plug-in available for a component.
  • technology: The technology node of the component. This attribute is required for all components. It is automatically propagated from declaration to compound component to subcomponents, even if not explicitly specified.
  • global_cycle_seconds: The global cycle time in seconds. This attribute is required for all components. It is automatically propagated from declaration to compound component to subcomponents, even if not explicitly specified. It is also propagated as arguments to actions.
  • n_components: The number of components. This attribute is required for all components. It is automatically propagated from declaration to compound component to subcomponents, even if not explicitly specified. It is also propagated as arguments to actions.

A Complete Example

accessibility