The AMALTHEA hardware model is used to describe hardware systems which usually consist of ECU, micro controllers, 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 different 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 FeaturesCategories 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 |
| Structures | Containment | HwStructure | * | Hierarchical structure of the hardware model |
The example in figure xxx is representative for any kind of definition in the model. This means for specifying a compute resource a ProcessingUnitDefinition is created once which is then referenced by the number of ProcessingUnit instances of this kind. For a ProcessingUnitDefinition the references to HwFeatures is on of the key concepts of the hardware model.
| 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 |
The example in figure xxx is representative for any kind of definition in the model. This means for specifying a memory, a MemoryDefinition is created once which is then 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 |
For specifying a cache, a CacheDefinition is created once which is then 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 | Percentag 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 once which is then referenced by the number of ConnectionHandler instances of this kind.
| 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) |
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 if hierarchical systems can be expressed. By setting the structure type attribute (e.g. Cluster, ECU) the structural level in the hardware is directly expressible in the model.
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 on the top level. 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 |
| 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. For this extension a general Amalthea mode concept is necessary.
| 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. For this extension a general Amalthea mode concept is necessary.
| 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. The cost function ( Recipes) of an algorithm will be placed in an intermediate layer outside of the hardware model in future. However the HwFeatures will be directly referenced by the Recipes. All HwFeatures are placed inside a_ProcessingUnitDefinition_, in Future we will extend the Feature concept for MemoryDefinitions, CacheDefinitions and ConnectionHandlerDefinitions. Specific definitions for the basic components are able to reference such HwFeatures to express their functionality. HwFeatures could be reused several times by different definitions. A HwFeature can contain a value to express static costs in a model. Figure �#fig:hwFeature_example shows an example how recipes are used in a model. NOTE: The Recipes and the HwFeatures concept is still work in progress. Changes to the 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 |
| 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 ProcessingUnit can be referenced by AccessPaths and HwAccessElements. The ProcessingUnits are the master modules in the model and every ProcessingUnit can has their own access space.
| 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, 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 an 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 HwConnections and an InternalConnection. The following figure shows an example with delegated HwPorts and InternalConnections.
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).
| 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 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 |
A LatencyConstant is used to determine a constant number of clock cycles and can be attached to various other elements e.g. access latencies for a MemoryDefinition or a read latency for a ConnectionHandlerDefinition .
| Attribute | Type | Value | Mul. | Description |
|---|---|---|---|---|
| Cycles | Long | Long | 1 | Constant number of clock cycles (default = 0) |
A LatencyDeviation is an object which allows to create a distribution out of different possibilities e.g. Weibull, Gaussian etc. The_LatencyDeviation_ can be attached to various elements e.g. access latencies for a MemoryDefinition or a read latency for a ConnectionHandlerDefinition .
| Attribute | Type | Value | Mul. | Description |
|---|---|---|---|---|
| Cycles | Deviation | Deviation | 1 | Deviation for a specific element in clock cycles |
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.
In future there will be an option to extend the predefined enums with further port interfaces, hardware structure types etc. by selecting the option other. Then a second attribute field will appear to specify a custom entry. 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: