Compound 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.

If you have not gone through the definition of Components or Primitive Components, please take a look at the descriptions for better understanding of this seciton.

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.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.
• 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:
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.

compound_components:
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 coompound 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
         ...

accessibility