Architecture

Accelergy shares the same tree-like architecture description as Timeloop does. However, instead of high-level description of the storage and compute units, which are in general referred to as components, Accelergy understands more details of each component and is responsible for generating accurate energy and area estimations.

First, Accelergy understands more classes of components than Timeloop does. For example, from Timeloop's perspective, there is no difference between a register file and a SRAM, both of which are simply treated as the storage class. Similary, there is no difference between a integer adder and an integer multipllier, both of which are treated as compute class. However, for Accelergy, a concerete description of the exact hardware implementations is crucial to derive accurate energy and area estimations.

Furthermore, each accelerator design often has its own unique hardware units with user-defined attributes. So instead of only looking for predefined attributes like Timeloop does, Accelergy is capable of understanding arbirary component descriptions.

As a result, for accurate Accelergy chracterization, the architecture description often includes lower level component classes and more detailed attributes assocaited with each class. We include more details about the supported components and the way of specifying your own components in the Components page.

In addition to the basic keywords associated with setting up the hardware organization (e.g, subtree, local), Accelergy understands some additional keywords:

• subclass: class name for the lower level hardware implementation. The class could be one from either the primitive component library or the user-defined compound component class input.
• more user defined attributes names under attribute key for each component.

The subclass keyword

In addition to the default class keyword that's understandable by both Timeloop and Accelergy. Accelergy also allows user to specify the subclass, which describes a class name for a more detailed implementation description.

• The class can be a basic building block that's already defined by Accelergy in its primitive component library.
• This class name could also be a user-defined one, whcih must be defined in the user-provided compound component class input.

For example, we can define the implementation class name of a storage unit to be smartbuffer, which is defined as an example compound component class in compound component class input.

architecture:
   ...
   local:
   - name: Buffer
     class: storage
     subclass: smartbuffer
     attributes: 
     ...

User-defined attribute names

For each component in the architecture, Accelergy also understands more attributes, which can be defined by the user if the component belongs to a compound component class.

For example, the smartbuffer class can have a user-defined attribute name counter_width, which, if defined, can be captured and understood by Accelergy (once it parses the smartbuffer class definition provided in compound component class input).

architecture:
   ...
   local:
   - name: Buffer
     class: storage
     subclass: smartbuffer
     attributes: 
        depth: 256
        width: 64
        counter_width: 8
        ...