The AMALTHEA hardware model is used to describe hardware systems which usually consist of several hierarchical elements which contain processing units, memories, connections etc. It is accessible through the HWModel element and contains following top level elements:
The following tables describe the different model elements and their attributes in detail. For several elements short examples are attached.
The HwModel class is the root element of the hardware model. It always contains one or multiple HwStructures, PowerDomains and FrequencyDomains and optionally different HWFeaturesCategories for the HwModule definitions.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware model |
Definitions | Containment | HwDefinition | * | Definitions of ProcessingUnits, Memories, Caches and ConnectionHandlers |
Domains | Containment | HwDomain | * | Frequency- and PowerDomains |
FeatureCategories | Containment | HwFeatureCategory | * | FeatureCategory for the HwModel including HwFeatures |
Structures | Containment | HwStructure | * | Hierarchical structure of the hardware model |
Additional information about the definition concept in general can be found in the User Guide (see General Hardware Model Overview).
For specifying a compute resource a ProcessingUnitDefinition is created, which is afterwards referenced by the number of ProcessingUnit instances of this kind. A ProcessingUnitDefinition can reference multiple HwFeatures to express different costs for different operations but only one HwFeature per HwFeatureCategory.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the processing unit definition |
PuType | Enum | PuType | 1 | Type of the processing unit e.g. (Core, GPU, etc.) |
Features | Reference | HwFeature | * | Hardware features of the definition |
For specifying a memory, a MemoryDefinition is created, which is afterwards referenced by the number of Memory instances of this kind.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the memory definition |
AccessLatency | Containment | HwLatency | 1 | Constant or distribution of access latency in cycles |
DataRate | Containment | DataRate | 1 | Max. data rate for the memory |
Size | Containment | Size | 1 | Size of the memory |
MemoryType | Enum | MemoryType | 1 | type of the memory (e.g. DRAM, Flash, SRAM, PCM) |
For specifying a cache, a CacheDefinition is created, which is afterwards referenced by the number of Cache instances of this kind.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the memory definition |
AccessLatency | Containment | HwLatency | 1 | Constant or distribution of access latency in cycles |
Size | Containment | Size | 1 | Size of the memory |
CacheType | Enum | CacheType | 1 | Cache type (e.g. data, instruction) |
WriteStrategy | Enum | WriteStrategy | 1 | Cache write strategy (e.g. write-back) |
Coherency | Bool | Bool | 1 | Cache coherency (default = false) |
Exclusive | Bool | Bool | 1 | Exclusive cache (default = false) |
Line Size | Int | Int | 1 | Line size in bits |
Hit Rate | Double | Double | 1 | Percentage hit rate of the cache(default = 0.0) |
NWays | Int | Int | 1 | N ways associative (default = 0) |
For specifying a bus or Interconnect etc., a ConnectionHandlerDefinition is created, which is afterwards referenced by the number of ConnectionHandler instances of this kind.
The figures shows an example of the attribute MaxConcurrentTransfers with the default value 1. This means that all ConnectionHandlers which are referencing this ConnectionHandlerDefinition can only handle 1 active transfer request at a time. All other requests have to wait until the current transfers has finished.
The next figure shows an example with a number of MaxConcurrentTransfers of 3. In this case the ConnectionHandler can handle up to 3 concurrent requests.
The value for MaxConcurrentTransfers has to be smaller or equal then the min(initiator ports, responder ports).
The values for DataRate, ReadLatency, and WriteLatency are default values for all ConnectionHandlers of this kind. For a specific InternalConnection in a ConnectionHandler instance other values can be assigned.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the memory definition |
SchedPolicy | Enum | SchedPolicy | 1 | Enumeration of different scheduling policies |
ReadLatency | Containment | HwLatency | 1 | Constant or distribution in cycles for a read access |
WriteLatency | Containment | HwLatency | 1 | Constant or distribution in cycles for a write access |
DataRate | Containment | DataRate | 1 | Max. data rate of the connection (value and unit) |
MaxBurstSize | Int | Int | 1 | Maximum burst size of a ConnectionHandler (default = 1) |
MaxConcurrentTransfers | Int | Int | 1 | Number of concurrent transfers from different initiator to responder ports (default = 1) |
A HwStructure is a hierarchical element which can contain all kind of HwModules, HwConnections and other HwStructures. Different HwStructures can be connected via one or more HwPorts with other structures or modules of a top level HwStructures. By combining different HwStructures any kind of hierarchical system can be expressed. By setting the structure type attribute (e.g. Cluster, ECU) the structural level in the hardware is directly expressible.
The figure shows an example for creating a hierarchy within an E/E-architecture. The HwStructure System (which is called “System”) is created as top level structure within the HwModel. It contains three other structures which represents different ECUs. The structures are connected via HwPorts, HwConnections and a ConnectionHandler. Usually structures in the model can be viewed as black boxes which can be connected via HwPorts. ECU3 allows a look inside, where additional structures for two SoCs are visible.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware structure |
StructureType | Enum | StructureType | 1 | Defines the type of the structure (e.g. ECU) |
Modules | Containment | HwModule | * | Modules of the structure (e.g. Memory) |
Ports | Containment | HwPort | * | Ports to connect the structure (always delegated Ports) |
Structures | Containment | HwStructure | * | Hardware structure to build hierarchical designs |
Connections | Containment | HwConnection | * | Connections within a structure |
The figure shows an example for HwDomain ( FrequencyDomain and a PowerDomain). They are always created at the top level in the root element HwModel. Every basic component is able to reference a FrequencyDomain and a PowerDomain. (Note: The link between domains and modules are only references, there are no visible connections inside the model)
A FrequencyDomain is inherited from HwDomain. This element describes a frequency domain which can be referenced by all elements of the type HwModule to define the default frequency value for operation. In future the FrequencyDomain should also contain possibleValues which should specify the different frequencies for different operation modes.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the frequency domain |
DefaultValue | Containment | Frequency | 1 | Default frequency value |
Clock Gating | Boolean | Boolean | 1 | Possibility to power down the domain (default = false) |
A PowerDomain is inherited from HwDomain. This element describes a power domain which can be referenced by all elements of the type HwModule, to define the default voltage value for operation. In future the PowerDomain should also contain possibleValues which should specify the different voltages for different operation modes.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the power domain |
DefaultValue | Containment | Voltage | 1 | Default voltage value |
PowerGating | Boolean | Boolean | 1 | Possibility to power down the domain (default = false) |
A
HwFeature is an abstract element to represent any kind of special functionality of a
ProcessingUnitDefinition.
HwFeatures could be reused several times by different definitions and organized within
HwFeatureCategories. Currently this
HwFeatureCategories are directly referenced out of the Software Model in future the cost function (
Recipes) of an algorithm will be placed in an additional intermediate layer.
More information can be found in (see Hardware Concepts).
NOTE: The concepts “Recipe” and “Hardware Features” are work in progress. Changes to the already implemented HwFeatures are probable.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware feature |
Value | Containment | Value | 1 | assigned factor to the corresponding feature |
The
HwFeatureCategory is an element to collect the same kind of
HwFeatures with different values.
The
HwFeatureCategories can be referenced by the
ExecutionNeeds in the Software Model.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware feature |
Type | Enum | HwFeatureType | 1 | Type to express the purpose of the feature (performance, power, performance_and_power) |
Description | String | String | 1 | Textual description of the hardware feature |
HwFeature | Containment | HwFeature | * | Hardware feature with a factor |
A ProcessingUnit is a HwModule that can be used to model a wide set of different hardware components like a GPU, hardware accelerator, CPU, etc. The capability and the functionality of a ProcessingUnit are represented by different HwFeatures within the ProcessingUnitDefinition. The ProcessingUnits are the master modules in the model and every ProcessingUnit can has their own access space. The ProcessingUnit can be referenced by AccessPaths and HwAccessElements.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the processing unit instance |
Ports | Containment | HwPort | * | Ports of the component |
Caches | Containment | Cache | * | Included caches by the Processing Unit e.g. L1 Cache |
AccessElements | Containment | AccessElement | * | Access element for a specific memory or processing unit |
FrequencyDomain | Reference | FrequencyDomain | 1 | Frequency domain which supplies the module with a frequency |
PowerDomain | Reference | PowerDomain | 1 | Power domain which supplies the module with a voltage |
Definition | Reference | ProcessingUnitDefinition | 1 | Definition with all features for the processing unit instance |
A Memory is a component of type HwModule to express any kind memory like SRAM (Scratchpads), DRAM, Flash, etc. in the model, caches are modeled separately. The Memory element can be referenced as destination by a HwAccessElement.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the memory instance |
Ports | Containment | HwPort | * | Ports of the component |
FrequencyDomain | Reference | FrequencyDomain | 1 | Frequency domain which supplies the module with a frequency |
PowerDomain | Reference | PowerDomain | 1 | Power domain which supplies the module with a voltage |
Definition | Reference | MemoryDefinition | 1 | Definition with all features for the memory instance |
A Cache is a component of type HwModule to express the special behavior of a Cache. It is used to create cache topologies within a system. The Cache can be referenced by AccessPaths to express if it is a cached or non-cached access. It is also the only HwModule which can be directly contained by a ProcessingUnit.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the cache instance |
Ports | Containment | HwPort | * | Ports of the component |
FrequencyDomain | Reference | FrequencyDomain | 1 | Frequency domain which supplies the module with a frequency |
PowerDomain | Reference | PowerDomain | 1 | Power domain which supplies the module with a voltage |
Definition | Reference | CacheDefinition | 1 | Definition with all features for the cache instance |
A ConnectionHandler is a component of type HwModule which can be used whenever multiple HwConnections, (HwPorts) have to be combined. It is possible to represent whole bus systems or interconnects with a single ConnectionHandler, or elements like small routers within a NoC.
The figure shows an example where a ConnectionHandler is used as an interconnect within a SoC. Optional it is possible to model InternalConnections inside a ConnectionHandler to model explicit or restrict different connections. However it is also possible to use default read and write latencies of the whole ConnectionHandlerDefinition, individual latencies can be attached to InternalConnections. A short example where a ConnectionHandler is used as a CAN bus is illustrated in the structure example. For detailed models where all modules connected via HwConnections and different ConnectionHandlers, the ConnectionHandlers should be the only module where contentions in the hardware model can occur. A ConnectionHandler can be referenced by HwAccessPaths.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the connection handler instance |
Ports | Containment | HwPort | * | Ports of the component |
InternalConnections | Containment | HwConnection | * | Internal connection between the ports |
FrequencyDomain | Reference | FrequencyDomain | 1 | Frequency domain which supplies the module with a frequency |
PowerDomain | Reference | PowerDomain | 1 | Power domain which supplies the module with a voltage |
Definition | Reference | ConnectionHandlerDefinition | 1 | Definition with all features for the connection handler instance |
A HwAccessElement can be used to specify the access relationship between two ProcessingUnits or a ProcessingUnit and a Memory. With multiple HwAccessElements the whole access or even address space of a ProcessingUnit can be represented. A HwAccessElement represents always the view from a specific ProcessingUnit. There exist two different approaches to express latency or a data rate for a HwAccessElement: 1. directly using latencies or data rates or 2. modeling the exact path to the destination by attaching a HwAccessPath which references the specific connection elements like ConnectionHandlers, HwConnection, etc. For the second approach it is also possible to work directly with addresses.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the address element |
Destination | Reference | HwDestination | 1 | Destination for the processing unit |
AccessPaths | Containment | HwAccessPath | 1 | Access path to the destination |
ReadLatency | Containment | HwLatency | 1 | Read latency to the destination |
WriteLatency | Containment | HwLatency | 1 | Write latency to the destination |
DataRate | Containment | DataRate | 1 | Max. data rate to the destination |
HwPorts are elements which can be connected via HwConnections. Every module can contain multiple HwPorts. Every communication, input or output is handled via a HwPort of a component. It is only allowed to have one HwConnection per HwPort, except the HwPort is categorized as delegated port which means it is just a hierarchical connection between HwStructures. In this case the ports can have two HwConnections. The second exception is if inside a ConnectionHandler, InternalConnections are used.In this case a HwPort can be directed with a HwConnection and InternalConnections. The following figure shows an example with delegated HwPorts and InternalConnections.
In case the BitWidth becomes important (e.g. to calculate the amount of data which is transfered over an ConnectionHandler) the minimum BitWidth of all included Ports have to be accounted.
For HwPorts it’s always possible to select if the port is an initiator or a responder port. The following example shows that an initiator port is always connected to a responder port (comparable to TLM modeling).
In case of a delegated port (which is used as hierarchical port at a HwStructure) the PortType of the module inside the structure is reflected. The following figure shows four different examples. The ports which are delegated are marked grey.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware port |
BitWidth | Int | Int | 1 | Bit width e.g. 32 bit (default = 0) |
Priority | Int | Int | 1 | Priority of the hardware port (default = 0) |
Type | Enum | PortType | 1 | Port type (initiator, responder) |
Delegated | Bool | Bool | 1 | Delegated ports are hierarchical structure ports |
PortInterface | Enum | PortInterface | 1 | Type to express special interfaces for validation |
A HwConnection is an element to model structural connections between two HwPorts. HwConnections are always placed within HwStructures. It is possible to directly annotate a read and write latency at a HwConnection. HwConnections can be referenced by HwAccessPaths. The HwConnection do not have a reference to a FrequencyDomain, the frequency is always provided by the element which is in front of the HwConnection in the HwAccessPath.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware connection |
Port1 | Reference | HwPort | 1 | Port1 for the connection |
Port2 | Reference | HwPort | 1 | Port2 for the connection |
ReadLatency | Containment | HwLatency | 1 | Constant or distribution in cycles for a read access |
WriteLatency | Containment | HwLatency | 1 | Constant or distribution in cycles for a write access |
DataRate | Containment | DataRate | 1 | Max. data rate of the connection (value and unit) |
A HwAccessPath is an element to describe the connection route of a ProcessingUnit to its destination ( Memory or ProcessingUnit). The HwAccessPath is defined through an ordered list of IPaths interface elements ( HWConnections, Caches and ConnectionHandlers) and is a containment of an HwAccessElement. The figure shows an example of an HwAccessPath, how a ProcessingUnit is connected via two HwConnections and a ConnectionHandler with a Memory.
In the following example the possible memOffset attribute is explained. Every ProcessingUnit can access a Memory or other ProcessingUnit over a different address. The size of the Memory has to be equal or greater than endAddress minus the startAddress.
In the case the the ProcessingUnit should not start at address 0 (from the memory point of view) the memOffset attribute can be used. With help of this attribute the access area for the memory can be changed, the following figure shows an example.
Attribute | Type | Value | Mul. | Description |
---|---|---|---|---|
Name | String | String | 1 | Name of the hardware access path |
PathElements | Reference | HwPath | * | Path elements for the access path |
StartAddress | Long | Long | 1 | Start address for the memory |
EndAddress | Long | Long | 1 | End address for the memory |
MemOffset | Long | Long | 1 | Offset for accessing only a partition of a memory |
In the following all enums are listed. In the case an enum is used by any class the default value of that enum is always undefined. That means that in case of an enum there are no default values for interfaces or other kind of types. Moreover only new enums are explicitly mentioned in this report. Enums and classes which are already part of the existing Amalthea meta model are not described.
StructureType:
CacheType:
VoltageUnit:
PortType:
SchedPolicy:
WriteStrategy:
PuType:
PortInterfaces:
HwFeatureType:
MemoryType: