WP6-17: Difference between revisions
Line 26: | Line 26: | ||
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. | 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|frame|center| Reference ESL HW/SW Co-Design Flow]] | [[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. | 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. |
Revision as of 19:08, 22 September 2022
HW/SW CO-DEsign of HEterogeneous Parallel dedicated Systems (HEPSYCODE)
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.
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