WP6-34 - Revision history

Grolleaue: /* HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2) */

2023-03-10T08:41:21Z

HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2)

← Older revision		Revision as of 08:41, 10 March 2023
Line 18:		Line 18:
	\|-		\|-
	\| TRL \|\| 4		\| TRL \|\| 4
			\|-
			\| Contact \|\| mario.diferdinando at univaq.it
	\|}		\|}

Univaq at 12:42, 3 October 2022

2022-10-03T12:42:35Z

← Older revision		Revision as of 12:42, 3 October 2022
Line 24:		Line 24:
	== 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==

Univaq at 12:40, 3 October 2022

2022-10-03T12:40:34Z

← Older revision		Revision as of 12:40, 3 October 2022
Line 24:		Line 24:
	== Detailed Description ==		== 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) [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, 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).

	==Contribution and Improvements==		==Contribution and Improvements==

Univaq at 12:39, 3 October 2022

2022-10-03T12:39:57Z

← Older revision		Revision as of 12:39, 3 October 2022
Line 20:		Line 20:
	\|}		\|}

	HEPSIM2 (i.e., HEPSYCODE Simulator Version 2.0) 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 ([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].		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 ==		== Detailed Description ==

Univaq at 12:39, 3 October 2022

2022-10-03T12:39:35Z

← Older revision		Revision as of 12:39, 3 October 2022
Line 20:		Line 20:
	\|}		\|}

	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 ([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].		HEPSIM2 (i.e., HEPSYCODE Simulator Version 2.0) 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 ([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 ==		== Detailed Description ==

Univaq at 19:51, 22 September 2022

2022-09-22T19:51:07Z

← Older revision		Revision as of 19:51, 22 September 2022
Line 7:		Line 7:
	\| Levels \|\| Tool, Platform		\| Levels \|\| Tool, Platform
	\|-		\|-
	\| Require \|\| Linux, ~~TODO~~		\| Require \|\| Linux, SystemC code
	\|-		\|-
	\| Provide \|\| ~~TODO~~		\| Provide \|\| Timing/Energy Co-Simulation
	\|-		\|-
	\| Input \|\| SystemC models, Platform model~~, TODO~~		\| Input \|\| SystemC models, Platform model
	\|-		\|-
	\| Output \|\| ~~TODO.~~		\| Output \|\| Logs and performance metrics
	\|-		\|-
	\| C4D tooling \|\| n.a.		\| C4D tooling \|\| n.a.

Univaq at 19:44, 22 September 2022

2022-09-22T19:44:27Z

← Older revision		Revision as of 19:44, 22 September 2022
Line 44:		Line 44:
	[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.		[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.		[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/.		[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		[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		[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)		[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		[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

Univaq at 19:43, 22 September 2022

2022-09-22T19:43:43Z

← Older revision		Revision as of 19:43, 22 September 2022
Line 46:		Line 46:
	[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.		[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.~~hespsycode~~.com.		[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		[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

Univaq at 19:43, 22 September 2022

2022-09-22T19:43:21Z

← Older revision		Revision as of 19:43, 22 September 2022
Line 20:		Line 20:
	\|}		\|}

	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].		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 ([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 ==		== 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).		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) [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).

	==Contribution and Improvements==		==Contribution and Improvements==
Line 41:		Line 41:

	==References==		==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.hespsycode.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

Univaq at 19:40, 22 September 2022

2022-09-22T19:40:38Z

← Older revision		Revision as of 19:40, 22 September 2022
Line 30:		Line 30:

	* 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.		* 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 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 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.		*# 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.