---
title: Components
url: 'https://timeloop.csail.mit.edu/v4/input-formats/design/components'
markdown: 'https://timeloop.csail.mit.edu/v4/input-formats/design/components.md'
date: '2024-08-15'
description: '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, pro…'
---

[](#)  [ Overview ](https://timeloop.csail.mit.edu/)     [ Timeloop+Accelergy v4 ](https://timeloop.csail.mit.edu/v4)     [ Input Formats ](https://timeloop.csail.mit.edu/v4/input-formats)     [ Design ](https://timeloop.csail.mit.edu/v4/input-formats/design)      Components    

# 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](https://timeloop.csail.mit.edu/v4/input-formats/design/components/./architecture).

## 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:

```yaml
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.

```yaml
compound_components:
   ...
  classes:
     ...
```

## The `name` key

Each component class is associated with a name.

```yaml
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.

```yaml
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`.

```yaml
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:

```yaml
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.

```yaml
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

```yaml

```

[accessibility](https://accessibility.mit.edu/)

---

## Navigation

- Parent: [Design](https://timeloop.csail.mit.edu/v4/input-formats/design.md)
- Previous: [Constraints](https://timeloop.csail.mit.edu/v4/input-formats/design/constraints.md)