WP6-17

HW/SW CO-DEsign of HEterogeneous Parallel dedicated Systems (HEPSYCODE)

ID	WP6-HEPSYCODE
Contributor	UNIVAQ
Levels	Tool, Platform
Require	Linux, SystemC code, UML/MARTE model
Provide	Architectural solutions
Input	SystemC models, Platform model
Output	HW/SW Partitioning, Mapping and Architecture Definition
C4D tooling	n.a.
TRL	4
Contact	mario.diferdinando at univaq.it

The increasing complexity of nowadays embedded digital systems, especially those based on advanced system-on-chip (SoC) that explicitly use heterogeneous parallel architectures (e.g., [1][2]) 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 [3]. 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 (e.g., [4][5][6][7]), 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. More details about the whole methodology can be found in [4][5][6][7].

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) [8], 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) [5]. 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

The design activity in HEPSYCODE begins with a high-level abstraction modeling language (called HEPSYCODE Modeling Language, HML). The initial HML model is then transformed into an executable SystemC model based on the Communicating Sequential Processes (CSP) Model of Computation (MoC), first described by Hoare [9]. HEPSYCODE defines two system-level models, the SBM and the TL. The former is realized from the original HML. The latter contains all necessary and low-level hardware architectural details (e.g., PUs, MUs, CUs). Such models are supported by some C++ libraries that extend the standard SystemC library to implement CSP. The language of Communicating Sequential Processes (CSP) was developed for describing systems of interacting components and is supported by an underlying theory for reasoning about them. CSP processes are modeled by using classic SC_THREAD while CSP channels have been modeled by introducing a proper sc_csp_channel as better described later. A “CSP SC_THREAD” presents an init section and an infinite loop behavior while accessing only its local variables and so communicating with other “CSP SC_THREAD” only by means of CSP channels. Finally, in a “CSP SC_THREAD”, only basic C/C++ statements and C++/SystemC data types are allowed while avoiding a full OOP approach since it could introduce critical issues for estimation and HW synthesis activities (in fact, the adopted restrictions have been inspired by [10]). Since the SBM is based on CSP, the SystemC library has been extended to properly model CSP channels with a sc_csp_channel class. HEPSYCODE supports the UML/MARTE modeling language for system modeling. The integration of UML/MARTE allows the designer to use one of the most used languages in the embedded systems industry. Moreover, MARTE is a standard UML profile to represent quantitative non-functional properties (e.g., time, performance). This variant of HEPSYCODE provides several steps of verification and validation (V&V) intending to discover eventual design flaws before the implementation. The novelty lies in the adoption of formal models to check the satisfiability of non-functional requirements and estimate system properties.

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:

HEPSYCODE interoperability graph

References

[1] “Xilinx Zynq SoC family”, http://www.xilinx.com

[2] “Intel/Altera Cyclone V family”, http://www.intel.com

[3] J. Teich. “Hardware/software co-design: The past, the present, and predicting the future”. Proceedings of the IEEE, 100 (Special Centennial Issue):1411-1430, May 2012.

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

[5] 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.

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

[7] 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

[8] Frank Vahid and Tony Givargis. 2001. “Embedded System Design: A Unified Hardware/Software Introduction”. John Wiley & Sons, Inc.

[9] C. A. R. Hoare. 1978. “Communicating sequential processes”. Commun. ACM 21, 8 (Aug. 1978), 666–677.

[10] “SystemC Synthesis Subset Language Reference Manual”, https://www.accellera.org/community/systemc