WP6-34: Difference between revisions

From COMP4DRONES
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 18: Line 18:
|-
|-
|  TRL || 4
|  TRL || 4
|-
| Contact || mario.diferdinando at univaq.it
|}
|}


Line 24: Line 26:
== Detailed Description ==
== Detailed Description ==


HEPSIM2 is based on SystemC, and the HEPSIM2 System Behaviour Model (SBM, i.e., the application model, see HEPSYCODE wiki page) is based on the CSP (Communicating Sequential Processes) Model of Computation (MoC) [5]. 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 [7] but combined with offline statement-level timing estimations [6] 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 ([1][2][3][4]) 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).
HEPSIM2 is based on SystemC, and the HEPSIM2 System Behaviour Model (SBM, i.e., the application model, see HEPSYCODE wiki page) is based on the CSP (Communicating Sequential Processes) Model of Computation (MoC) [5]. 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 [7] but combined with offline statement-level timing estimations [6] 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 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 ([1][2][3][4]) 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==
==Contribution and Improvements==

Latest revision as of 08:41, 10 March 2023

HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2)

ID WP6-HEPSIM2
Contributor UNIVAQ
Levels Tool, Platform
Require Linux, SystemC code
Provide Timing/Energy Co-Simulation
Input SystemC models, Platform model
Output Logs and performance metrics
C4D tooling n.a.
TRL 4
Contact mario.diferdinando at univaq.it

HEPSIM2 (i.e., HEPSYCODE Simulator Version 2.0) is a SystemC-based tool for functional and timing/energy HW/SW co-simulation/analysis at the system-level, integrated into a reference Electronic System-Level (ESL) HW/SW co-design methodology, called HEPSYCODE ([1][2][3][4]), 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 HEPSYCODE wiki page) is based on the CSP (Communicating Sequential Processes) Model of Computation (MoC) [5]. 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 [7] but combined with offline statement-level timing estimations [6] 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 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 ([1][2][3][4]) 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:
    1. 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%.
    2. 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:

HEPSIM2 interoperability graph

References

[1] L. Pomante. “System-level design space exploration for dedicated heterogeneous multi-processor systems”. IEEE Int. Conf. on Application-specific Systems, Architectures and Processors, 2011.

[2] L. Pomante, D. Sciuto, F. Salice, W. Fornaciari, C. Brandolese. “Affinity-Driven System Design Exploration for Heterogeneous Multiprocessor SoC”. IEEE Transactions on Computers, vol. 55, no. 5, May 2006.

[3] “HEPSYCODE”, https://www.hepsycode.com/.

[4] Pomante, L., Muttillo, V., Santic, M., Serri, P. “SystemC-based electronic system-level design space exploration environment for dedicated heterogeneous multi-processor systems”. Microprocessors and Microsystems, 72, 2020

[5] Hoare C.A.R. (1978) “Communicating Sequential Processes”. In: Hansen P.B. (eds) The Origin of Concurrent Programming. Springer, New York, NY

[6] V. Muttillo, G. Valente, L. Pomante, V. Stoico, F. D’Antonio, and F. Salice, “CC4CS: an Off-the-Shelf Unifying Statement-Level Performance Metric for HW/SW Technologies”, In Companion of the 2018 ACM/SPEC Int. Conf. on Performance Engineering (ICPE '18)

[7] L. Diaz, E. Gonzalez, E. Villar and P. Sanchez, "VIPPE, parallel simulation and performance analysis of multi-core embedded systems on multi-core platforms," Design of Circuits and Integrated Systems, Madrid, 2014, pp. 1-7