## Hardware Model

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:

- Definitions
- Domains
- Features
- Structures

### Class Diagrams

#### Hardware model elements

#### Hardware definitions and features

#### Hardware modules and access elements

#### Hardware paths and destinations

### Element description

The following tables describe the different model elements and their attributes in detail. For several elements short examples are attached.

#### HwModel

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

#### HwDefinition

Additional information about the definition concept in general can be found in the User Guide (see General Hardware Model Overview).

##### ProcessingUnitDefinition

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

##### MemoryDefinition

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)

##### CacheDefinition

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)

##### ConnectionHandlerDefinition

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)

#### HwStructure

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

#### HwDomain

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)

##### FrequencyDomain

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)

##### PowerDomain

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)

#### HwFeature

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

##### HwFeatureCategory

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

#### HwModule

##### ProcessingUnit

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

##### Memory

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

##### Cache

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

##### ConnectionHandler

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

#### HwAccessElement

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

#### HwPort

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 BithWidth 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

#### HwConnection

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)

#### HwAccessPath

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.

- memory_size >= endAddress – 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

#### Enumerations

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:

- _undefined_, System, ECU, Microcontroller, SoC, Cluster, Group, Array, Area, Region

CacheType:

- _undefined_, instruction, data, unified

VoltageUnit:

- _undefined_, V, mV, uV

PortType:

- _undefined_, initiator, responder

SchedPolicy:

- _undefined_, RoundRobin, FCFS, PriorityBased

WriteStrategy:

- _undefined_, none, writeback, writethrough

PuType:

- _undefined_, GPU, CPU, Accelerator

PortInterfaces:

- _undefined_, custom, can, flexray, lin, most, ethernet, spi, i2c, axi, ahb, apb, swr

HwFeatureType:

- _undefined_, performance, power, performance_and_power

MemoryType:

- _undefined_, DRAM, SRAM, FLASH, PCM