2022-09-22T19:39:41Z

Univaq:

= HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2)=
{|class="wikitable"
| ID|| WP6-HEPSIM2
|-
| Contributor || UNIVAQ
|-
| Levels || Tool, Platform
|-
| Require || Linux, TODO
|-
| Provide || TODO
|-
| Input || SystemC models, Platform model, TODO
|-
| Output || TODO.
|-
| C4D tooling || n.a.
|-
| TRL || 4
|}

HEPSIM2 (i.e., HEPSYCODE Simulator 2) is a SystemC-based tool for functional and timing HW/SW co-simulation/analysis at the system-level, integrated into a reference Electronic System-Level (ESL) HW/SW co-design methodology, called HEPSYCODE ([35][36][37][38]), targeting heterogeneous parallel embedded systems. The following text describes the main features of the tool by mainly focusing on the improvements and extensions done in C4D with respect to a previous version [41].

== Detailed Description ==

HEPSIM2 is based on SystemC, and the HEPSIM2 System Behaviour Model (SBM, i.e., the application model, see the previous section about HEPSYCODE) is based on the CSP (Communicating Sequential Processes) Model of Computation (MoC) [39][43]. HEPSIM2 really works at ESL, i.e., at an abstraction layer similar to TLM but mainly considering only the behavioural view of the system. In fact, it allows considering the effects that the mapping on the HW platform would have on the system behaviour without the need to develop a corresponding TLM structural model. This is obtained by exploiting an approach inspired by the native simulation one [44] but combined with offline statement-level timing estimations [42] to avoid the need for binary code analysis. This feature allows a faster what-if analysis since it doesn’t require ISS or HDL integration into virtual platforms. The main drawback is the possible reduced accuracy in the timing performance estimation with respect to TLM analysis, but the proposed approach can be used to reduce the design space early and quickly by selecting the most promising “configurations” that can be then transformed into TLM (or RTL) models for more accurate analysis by means of specific tools. Moreover, other than performing functional and HW/SW timing co-simulations, HEPSIM2 is able to perform also co-analysis and co-estimations. In fact, it is able to provide information about communication and potential concurrency (both for processes and channels) in the CSP model. Moreover, it is able to perform the estimation of the loads that CSP-processes execution (and the bandwidth that CSP-channels communications) would impose, respectively, to processors and physical links, in order to satisfy imposed timing constraints. Such information, as described below, allows the reference ESL HW/SW co-design flow to exploit in a more effective way the targeted heterogeneous parallel embedded architecture. Finally, HEPSIM2 is strictly integrated into the HEPSYCODE ESL HW/SW co-design methodology ([35][36][37][38]) but it can be used also as a stand-alone tool relying on an HW architecture directly provided by the designer (i.e., manual DSE).

==Contribution and Improvements==
Some key aspects of the HEPSIM2 for analysis improvement are:

* HEPSIM2 simulation time is no more dependent on the time granularity related to the events generated by the environment. This feature has been obtained by re-designing the second-level schedulers used to model scheduling activities on GPP/ASP in order to reduce the overhead associated with the scheduling management and preserve usability and scalability.
* The improved second-level scheduler design provides better usability and scalability from two main points of view.
** The first is related to the scalability of the time intervals among different inputs from STIMULUS. With the old HEPSIM, a time interval of 1000 ms would be completely unfeasible due to the duration of the simulation. So, it is possible to state that, on average, simulation time has been reduced by an amount greater than 15%.
** The second analysis is related to the scalability with respect to the number of CSP processes and CSP channels in the SBM, and processors and schedulers in the HW/SW architecture. The strategy has been to create even more complex SBMs (by replicating several times a basic one) and simulating them by considering several architecture/mapping items built to mix GPP/ASP and SP.

== Interoperability with other C4D tools ==

HEPSIM2, the SystemC simulator used in HEPSICODE, has demonstrated interoperability with S3D in the ECSEL project MegaMart2. Interoperability with ESDE can be established with SystemC. HEPSIM2 simulations can be adapted to another Model of Computation such as Data Flow (DF), allowing integration with UNISS MDC and UNIMORE OODK. Therefore, the interoperability graph for HEPSIM2 is as follows:

[[File:wp6-34_1_01.png|300px|thumb|frame|center| HEPSIM2 interoperability graph]]

==References==

File:Wp6-34 1 01.png

2022-09-22T19:36:06Z

Univaq:

2022-09-22T19:11:22Z

Univaq:

WP6-17

2022-09-22T19:11:12Z

Univaq:

= HW/SW CO-DEsign of HEterogeneous Parallel dedicated Systems (HEPSYCODE)=
{|class="wikitable"
| ID|| WP6-HEPSYCODE
|-
| Contributor || UNIVAQ
|-
| Levels || Tool, Platform
|-
| Require || Linux, TODO
|-
| Provide || TODO
|-
| Input || SystemC models, Platform model, TODO
|-
| Output || TODO.
|-
| C4D tooling || n.a.
|-
| TRL || 4
|}

The increasing complexity of nowadays embedded digital systems, especially those based on advanced system-on-chip (SoC) that explicitly use heterogeneous parallel architectures to meet demanding timing performance and power consumption requirements, and their shorter time-to-market are radically changing standard industrial design methodologies. Traditional design approaches based on the independent design of HW / SW components are no longer sufficient to efficiently exploit sub-areas of such SoCs. For this reason, system-level HW/SW co-design methods, where designers can early check system-level constraints and evaluate tradeoffs between cost and performance, are becoming increasingly important. These methods are capable of guiding system-level activities using appropriate models, metrics, and tools, and assisting the designer in all those tasks normally entrusted only to his or her experience (e.g., HW / SW architecture definition and system-level HW /SW partitioning ). In this context, this repository presents a reference methodology for electronic system level (ESL) HW/SW co-design, called HEPSYCODE, targeting heterogeneous parallel embedded systems. It has been extended in C4D to meet mixed-criticality requirements and to be integrated into UML/MARTE specifications.

== Detailed Description ==

Figure below shows the reference ESL HW/SW co-design flow while its main steps are briefly described below by giving emphasis (red elements in Figure below) to the interactions with the HEPSIM2 simulator/analysis tool.

[[File:wp6-17_1_01.png|600px|thumb|frame|center| Reference ESL HW/SW Co-Design Flow]]

The entry point of the reference HW /SW co-design flow is the System Behaviour Model (SBM), which is based on a CSP -like MoC and described using SystemC. It is enriched by timing constraints (TCs) and reference inputs (RI). The first step of the reference flow, performed using HEPSIM2, is the functional simulation. It allows checking the correctness of the SBM with respect to RI. In the following steps, the reference ESL HW /SW co-design flow is supported by a Technologies Library (TL), which can be considered as a database that provides a characterization of all HW technologies used to define the so-called Basic Blocks (BBs) to build the final system. The TL contains information about available General-Purpose Processors (GPPs), Application Specific Processors (ASPs), Single Purpose Processors (SPPs), memory, and interconnects (i.e., physical links). The next step is co-analysis and co-estimation. During co-analysis, the SBM is analyzed to evaluate three metrics: affinity, communication, and concurrency. The first one represents how much a CSP process is suitable to be executed on a specific processor class (i.e., GPP, ASP, SPP). The second one is the evaluation of the number of bits that the various CSP process pairs exchanged over the corresponding CSP channels during simulation. The third refers to how many concurrencies have been found during the simulation in the activities of the CSP processes and CSP channels (it is evaluated using HEPSIM2 in a given configuration). Co-estimation is responsible for estimating timing, size, and load. Timing represents the time needed by each processor in the TL to execute an SBM statement. Size represents the number of bytes in RAM and ROM needed to store data and instructions for each CSP process implemented in SW. For the implementation of HW CSP processes, it is the number of mm2 (depending on the target HW technology, equivalent metrics such as Equivalent Gates, Look Up Table, etc. may be used) needed to implement processing, memory, and interconnect elements. Load represents the utilization percentage that each CSP process when implemented in SW, would impose on each GPP/ASP (used to define the BBs) to meet a timing constraint specified by the designer (i.e., it is actually a time to completion, TTC). After this step, the flow enters Design Space Exploration (DSE), which consists of 2 activities, "HW /SW Partitioning, Architecture Definition and Mapping" and "Timing HW /SW Co-simulation". The first activity is responsible for defining the HW architecture of the target system and for HW /SW partitioning and mapping processes and channels to available processors and physical connections. This data is then provided to HEPSIM2 to verify that the proposed architecture or mapping meets the timing constraints. Data exchange between the different steps of the entire ESL HW /SW co-design flow is supported by appropriate XML files.

==Contribution and Improvements==
Some key aspects of the HEPSYCODE flow for design system improvement are:

* TODO
* TODO

== Interoperability with other C4D tools ==

HEPSYCODE has demonstrated interoperability with S3D in the ECSEL project MegaMart2. Interoperability with ESDE can be established using SystemC simulation tool (HEPSIM2). Since the modeling methodology of Papyrus4Robotics is based on MARTE, potential interoperability with this tool seems possible with the new HEPSYCODE extension. HEPSYCODE models can be adapted to another Model of Computation such as Data Flow (DF), allowing integration with UNISS MDC and UNIMORE OODK. Therefore, the interoperability graph for HEPSYCODE is the following:

[[File:wp6-17_1_02.png|800px|thumb|frame|center| HEPSYCODE interoperability graph]]

==Current Status==

TODO

==Design and Implementation==

TODO

WP6-17

2022-09-22T19:08:18Z

Univaq:

= HW/SW CO-DEsign of HEterogeneous Parallel dedicated Systems (HEPSYCODE)=
{|class="wikitable"
| ID|| WP6-HEPSYCODE
|-
| Contributor || UNIVAQ
|-
| Levels || Tool, Platform
|-
| Require || Linux, TODO
|-
| Provide || TODO
|-
| Input || SystemC models, Platform model, TODO
|-
| Output || TODO.
|-
| C4D tooling || n.a.
|-
| TRL || 4
|}

The increasing complexity of nowadays embedded digital systems, especially those based on advanced system-on-chip (SoC) that explicitly use heterogeneous parallel architectures to meet demanding timing performance and power consumption requirements, and their shorter time-to-market are radically changing standard industrial design methodologies. Traditional design approaches based on independent design of HW / SW components are no longer sufficient to efficiently exploit sub-areas of such SoCs. For this reason, system-level HW/SW co-design methods, where designers can early check system-level constraints and evaluate tradeoffs between cost and performance, are becoming increasingly important. These methods are capable of guiding system-level activities using appropriate models, metrics, and tools, and assisting the designer in all those tasks normally entrusted only to his or her experience (e.g., HW / SW architecture definition and system-level HW /SW partitioning ). In this context, this repository presents a reference methodology for electronic system level (ESL) HW/SW co-design, called HEPSYCODE, targeting heterogeneous parallel embedded systems. It has been extended in C4D to meet mixed criticality requirements and to be integrated into UML/MARTE specifications.

== Detailed Description ==

Figure 23 shows the reference ESL HW/SW co-design flow while its main steps are briefly described below by giving emphasis (red elements in Figure 23) to the interactions with the HEPSIM2 simulator/analysis tool.

[[File:wp6-17_1_01.png|600px|thumb|frame|center| Reference ESL HW/SW Co-Design Flow]]

The entry point of the reference HW /SW co-design flow is the System Behaviour Model (SBM), which is based on a CSP -like MoC and described using SystemC. It is enriched by timing constraints (TCs) and reference inputs (RI). The first step of the reference flow, performed using HEPSIM2, is the functional simulation. It allows checking the correctness of the SBM with respect to RI. In the following steps, the reference ESL HW /SW co-design flow is supported by a Technologies Library (TL), which can be considered as a database that provides a characterization of all HW technologies used to define the so-called Basic Blocks (BBs) to build the final system. The TL contains information about available General-Purpose Processors (GPPs), Application Specific Processors (ASPs), Single Purpose Processors (SPPs), memory, and interconnects (i.e., physical links). The next step is co-analysis and co-estimation. During co-analysis, the SBM is analysed to evaluate three metrics: affinity, communication, and concurrency. The first one represents how much a CSP process is suitable to be executed on a specific processor class (i.e., GPP, ASP, SPP). The second one is the evaluation of the number of bits that the various CSP process pairs exchanged over the corresponding CSP channels during simulation. The third refers to how many concurrencies have been found during the simulation in the activities of the CSP processes and CSP channels (it is evaluated using HEPSIM2 in a given configuration). Co-stimation is responsible for estimating timing, size and load. Timing represents the time needed by each processor in the TL to execute an SBM statement. Size represents the number of bytes in RAM and ROM needed to store data and instructions for each CSP process implemented in SW. For the implementation of HW CSP processes, it is the number of mm2 (depending on the target HW technology,equivalent metrics such as Equivalent Gates, Look Up Table, etc. may be used) needed to implement processing, memory and interconnect elements. Load represents the utilization percentage that each CSP process, when implemented in SW, would impose on each GPP/ASP (used to define the BBs) to meet a timing constraint specified by the designer (i.e., it is actually a time to completion, TTC). After this step, the flow enters Design Space Exploration (DSE), which consists of 2 activities, "HW /SW Partitioning, Architecture Definition and Mapping" and "Timing HW /SW Co-simulation". The first activity is responsible for defining the HW architecture of the target system and for HW /SW partitioning and mapping processes and channels to available processors and physical connections. This data is then provided to HEPSIM2 to verify that the proposed architecture or mapping meets the timing constraints. Data exchange between the different steps of the entire ESL HW /SW co-design flow is supported by appropriate XML files.

==Contribution and Improvements==
Some key aspects of the HEPSYCODE flow for design system improvement are:

* TODO
* TODO

== Interoperability with other C4D tools ==

TODO

==Current Status==

TODO

==Design and Implementation==

TODO

WP6-17

2022-09-22T19:08:10Z

Univaq:

= HW/SW CO-DEsign of HEterogeneous Parallel dedicated Systems (HEPSYCODE)=
{|class="wikitable"
| ID|| WP6-HEPSYCODE
|-
| Contributor || UNIVAQ
|-
| Levels || Tool, Platform
|-
| Require || Linux, TODO
|-
| Provide || TODO
|-
| Input || SystemC models, Platform model, TODO
|-
| Output || TODO.
|-
| C4D tooling || n.a.
|-
| TRL || 4
|}

The increasing complexity of nowadays embedded digital systems, especially those based on advanced system-on-chip (SoC) that explicitly use heterogeneous parallel architectures to meet demanding timing performance and power consumption requirements, and their shorter time-to-market are radically changing standard industrial design methodologies. Traditional design approaches based on independent design of HW / SW components are no longer sufficient to efficiently exploit sub-areas of such SoCs. For this reason, system-level HW/SW co-design methods, where designers can early check system-level constraints and evaluate tradeoffs between cost and performance, are becoming increasingly important. These methods are capable of guiding system-level activities using appropriate models, metrics, and tools, and assisting the designer in all those tasks normally entrusted only to his or her experience (e.g., HW / SW architecture definition and system-level HW /SW partitioning ). In this context, this repository presents a reference methodology for electronic system level (ESL) HW/SW co-design, called HEPSYCODE, targeting heterogeneous parallel embedded systems. It has been extended in C4D to meet mixed criticality requirements and to be integrated into UML/MARTE specifications.

== Detailed Description ==

Figure 23 shows the reference ESL HW/SW co-design flow while its main steps are briefly described below by giving emphasis (red elements in Figure 23) to the interactions with the HEPSIM2 simulator/analysis tool.

[[File:wp6-17_1_01.png|800px|thumb|frame|center| Reference ESL HW/SW Co-Design Flow]]

The entry point of the reference HW /SW co-design flow is the System Behaviour Model (SBM), which is based on a CSP -like MoC and described using SystemC. It is enriched by timing constraints (TCs) and reference inputs (RI). The first step of the reference flow, performed using HEPSIM2, is the functional simulation. It allows checking the correctness of the SBM with respect to RI. In the following steps, the reference ESL HW /SW co-design flow is supported by a Technologies Library (TL), which can be considered as a database that provides a characterization of all HW technologies used to define the so-called Basic Blocks (BBs) to build the final system. The TL contains information about available General-Purpose Processors (GPPs), Application Specific Processors (ASPs), Single Purpose Processors (SPPs), memory, and interconnects (i.e., physical links). The next step is co-analysis and co-estimation. During co-analysis, the SBM is analysed to evaluate three metrics: affinity, communication, and concurrency. The first one represents how much a CSP process is suitable to be executed on a specific processor class (i.e., GPP, ASP, SPP). The second one is the evaluation of the number of bits that the various CSP process pairs exchanged over the corresponding CSP channels during simulation. The third refers to how many concurrencies have been found during the simulation in the activities of the CSP processes and CSP channels (it is evaluated using HEPSIM2 in a given configuration). Co-stimation is responsible for estimating timing, size and load. Timing represents the time needed by each processor in the TL to execute an SBM statement. Size represents the number of bytes in RAM and ROM needed to store data and instructions for each CSP process implemented in SW. For the implementation of HW CSP processes, it is the number of mm2 (depending on the target HW technology,equivalent metrics such as Equivalent Gates, Look Up Table, etc. may be used) needed to implement processing, memory and interconnect elements. Load represents the utilization percentage that each CSP process, when implemented in SW, would impose on each GPP/ASP (used to define the BBs) to meet a timing constraint specified by the designer (i.e., it is actually a time to completion, TTC). After this step, the flow enters Design Space Exploration (DSE), which consists of 2 activities, "HW /SW Partitioning, Architecture Definition and Mapping" and "Timing HW /SW Co-simulation". The first activity is responsible for defining the HW architecture of the target system and for HW /SW partitioning and mapping processes and channels to available processors and physical connections. This data is then provided to HEPSIM2 to verify that the proposed architecture or mapping meets the timing constraints. Data exchange between the different steps of the entire ESL HW /SW co-design flow is supported by appropriate XML files.

==Contribution and Improvements==
Some key aspects of the HEPSYCODE flow for design system improvement are:

* TODO
* TODO

== Interoperability with other C4D tools ==

TODO

==Current Status==

TODO

==Design and Implementation==

TODO

WP6-17

2022-09-22T19:08:01Z

Univaq:

= HW/SW CO-DEsign of HEterogeneous Parallel dedicated Systems (HEPSYCODE)=
{|class="wikitable"
| ID|| WP6-HEPSYCODE
|-
| Contributor || UNIVAQ
|-
| Levels || Tool, Platform
|-
| Require || Linux, TODO
|-
| Provide || TODO
|-
| Input || SystemC models, Platform model, TODO
|-
| Output || TODO.
|-
| C4D tooling || n.a.
|-
| TRL || 4
|}

The increasing complexity of nowadays embedded digital systems, especially those based on advanced system-on-chip (SoC) that explicitly use heterogeneous parallel architectures to meet demanding timing performance and power consumption requirements, and their shorter time-to-market are radically changing standard industrial design methodologies. Traditional design approaches based on independent design of HW / SW components are no longer sufficient to efficiently exploit sub-areas of such SoCs. For this reason, system-level HW/SW co-design methods, where designers can early check system-level constraints and evaluate tradeoffs between cost and performance, are becoming increasingly important. These methods are capable of guiding system-level activities using appropriate models, metrics, and tools, and assisting the designer in all those tasks normally entrusted only to his or her experience (e.g., HW / SW architecture definition and system-level HW /SW partitioning ). In this context, this repository presents a reference methodology for electronic system level (ESL) HW/SW co-design, called HEPSYCODE, targeting heterogeneous parallel embedded systems. It has been extended in C4D to meet mixed criticality requirements and to be integrated into UML/MARTE specifications.

== Detailed Description ==

Figure 23 shows the reference ESL HW/SW co-design flow while its main steps are briefly described below by giving emphasis (red elements in Figure 23) to the interactions with the HEPSIM2 simulator/analysis tool.

[[File:wp6-17_1_01.png|1000px|thumb|frame|center| Reference ESL HW/SW Co-Design Flow]]

The entry point of the reference HW /SW co-design flow is the System Behaviour Model (SBM), which is based on a CSP -like MoC and described using SystemC. It is enriched by timing constraints (TCs) and reference inputs (RI). The first step of the reference flow, performed using HEPSIM2, is the functional simulation. It allows checking the correctness of the SBM with respect to RI. In the following steps, the reference ESL HW /SW co-design flow is supported by a Technologies Library (TL), which can be considered as a database that provides a characterization of all HW technologies used to define the so-called Basic Blocks (BBs) to build the final system. The TL contains information about available General-Purpose Processors (GPPs), Application Specific Processors (ASPs), Single Purpose Processors (SPPs), memory, and interconnects (i.e., physical links). The next step is co-analysis and co-estimation. During co-analysis, the SBM is analysed to evaluate three metrics: affinity, communication, and concurrency. The first one represents how much a CSP process is suitable to be executed on a specific processor class (i.e., GPP, ASP, SPP). The second one is the evaluation of the number of bits that the various CSP process pairs exchanged over the corresponding CSP channels during simulation. The third refers to how many concurrencies have been found during the simulation in the activities of the CSP processes and CSP channels (it is evaluated using HEPSIM2 in a given configuration). Co-stimation is responsible for estimating timing, size and load. Timing represents the time needed by each processor in the TL to execute an SBM statement. Size represents the number of bytes in RAM and ROM needed to store data and instructions for each CSP process implemented in SW. For the implementation of HW CSP processes, it is the number of mm2 (depending on the target HW technology,equivalent metrics such as Equivalent Gates, Look Up Table, etc. may be used) needed to implement processing, memory and interconnect elements. Load represents the utilization percentage that each CSP process, when implemented in SW, would impose on each GPP/ASP (used to define the BBs) to meet a timing constraint specified by the designer (i.e., it is actually a time to completion, TTC). After this step, the flow enters Design Space Exploration (DSE), which consists of 2 activities, "HW /SW Partitioning, Architecture Definition and Mapping" and "Timing HW /SW Co-simulation". The first activity is responsible for defining the HW architecture of the target system and for HW /SW partitioning and mapping processes and channels to available processors and physical connections. This data is then provided to HEPSIM2 to verify that the proposed architecture or mapping meets the timing constraints. Data exchange between the different steps of the entire ESL HW /SW co-design flow is supported by appropriate XML files.

==Contribution and Improvements==
Some key aspects of the HEPSYCODE flow for design system improvement are:

* TODO
* TODO

== Interoperability with other C4D tools ==

TODO

==Current Status==

TODO

==Design and Implementation==

TODO

File:Wp6-17 1 01.png

2022-09-22T19:06:54Z

Univaq: