The COMPLEX Framework

MDA design entry

COMPLEX provides an MDA (Model Driven Architecture) design entry (a), using the MARTE UML profile as well as the Stateflow and Simulink tools. The platform independent model (PIM) specifies the application or behaviour model of the system. The use-case scenario of the PIM is defined using UML or Matlab/Simulink (b). The system specification model describes the system functionality and synchronisation points through abstract communication channels (e.g. handshake) and defines some kind of communication scheduling. The platform description model (PDM) (d) describes the interconnection of allocated execution and memory resources. The user-constrained HW/SW separation and mapping (c) describes the binding of the processes in the platform independent model to execution units and memories of the PDM.

Executable Specification

As the PIM is a pure specification model, for functional evaluation it is either simulated directly using the Mathworks tools, in order to analyse and optimise the network performance, or converted to an executable SystemC model (e) for the detailed platform design. This model contains functional descriptions of tasks that will run as user-defined hardware like ASICs, as software on a processor, or are provided as IP-components from third-party vendors. The latter ones are required just for functional simulation and are not being modified during the subsequent flow. In order to execute the SystemC model specified in (e), it needs to be stimulated. The stimuli (f) might originate from user interaction or communication with other components that are part of the environment. External system stimuli are derived from the MARTE use-case specifications or from the environment model in Stateflow/Simulink (b). The IP-XACT platform specification (g) consists of blocks (components) with interconnected interfaces. Each bock represents an IP component that can be configured and characterized by the use of meta-data annotations. IP-XACT allows different views on each IP component. To enable high-speed TLM simulation, a view with associated SystemC and OSCI TLM2 descriptions can be used. The IP component meta-data (area, delay, power, etc.) can be described by a non-functional view. The IP-XACT description is generated from the MARTE PDM (d). From the IP-XACT platform specification a structural top-level view of the platform architecture is assembled. It consists of processing elements, dedicated hardware, memories, and interconnects. COMPLEX does not use interconnected RTL components but virtual platform IP components. Their behaviour is modelled in SystemC and their communication interfaces are OSCI TLM2 compliant. Consequently all interconnection models used in COMPLEX are also TLM2 compatible.

Figure 5
: The proposed COMPLEX Framework

Estimation & model generation

Step (h) collects all information from the executable specification phase, parses and analyses/elaborates the SystemC specification model, reads the mapping information, and the IP-XACT platform specification meta-data. All these information are written to an internal design representation. From that internal representation the behaviour description of each component can be extracted and forwarded to the domain specific analysis and synthesis tools. Behaviours mapped to dedicated HW resources (HW tasks) are forwarded to existing source analysis and behavioural synthesis tools (i). Behaviours mapped to SW resources, as general purpose processors or digital signal processors, are forwarded to existing source analysis and cross compilation tools (j). Additionally testbenches with activation traces and constraints for the behavioural synthesis and cross compilation are forwarded to these third party tools. HW tasks which shall be implemented in custom hardware enter block (i) together with typical input stimuli (input data and active/idle statistics) as well as synthesis constraints (such as technology node, threshold voltage, available area, etc.). Each task is then analysed and fully synthesised (scheduling, binding, allocation, implementation of power-management methodology, controller generation, floor-planning, etc.) down to RT-level using third party behavioural synthesis tools. Finally, code in BAC++ (Block Annotated C++) is generated. The BAC++ is clustered, in such way that run-time or power variable control structures, as well as bus requests are separated. Delay, static power, dynamic power, and variation information are instrumented to the behavioural C++ code so that a power and delay aware simulation can be performed via code execution. The SW task's code will be analyzed and cross-compiled by existing third party tools (j). During analysis metrics like power consumption and worst-case execution time are estimated and a model is generated from that data. Identically to the behavioural synthesis in (i) code in BAC++ is generated by the cross-compiler back-end. Block (k) represents SystemC/TLM2 performance and power characterized platform IP components like HW accelerators, communication resources (bus, point-to-point channel), and memories. The virtual system generator (l) reads the BAC++ from (i) and (j) and takes the instantiated virtual IP component models from (k). The virtual system generator assembles these different input blocks to an executable system model. Therefore, the instrumented code coming form (i) and (j) needs to be connected to the remaining virtual platform IP components, using the OSCI TLM2 API. The output of this generator is a complete performance and power aware system model with up to basic block accuracy.


The custom hardware, synthesized in (i) and parts of the virtual platform IP components, specified in (k) provide dynamic power management (DPM) abilities. For the first iteration of the entire DSE, an initial power controller (m) will be automatically generated, controlling each component’s power state based on the transition cost and the activity distribution. Afterwards, the DPM policies can be modified by the user or automatically refined. The generated SystemC model (n) can be compiled and directly executed on the host machine of the designer. The instrumented code (BAC++) allows writing different simulation traces under employment of the specified system input stimuli (f) through use-cases (b). The granularity of tracing information can be parameterized to the needs of the analysis and exploration step. It is expected that full tracing will slow down the entire simulation dramatically, which makes an appropriate choice of granularity extremely important. The tracing granularity can be chosen for each component independently and can be refined hierarchically. This allows a more fine-grained monitoring of certain interesting component’s behaviour and a more coarse-grained monitoring of other components.

In case of networked embedded systems, e.g., wireless sensor networks, COMPLEX will also address the simulation of communications among embedded systems since this aspect is significant in the assessment of the performance of the design solutions and therefore in the design-space exploration and optimisation.

Exploration & optimisation

The simulation trace (o) contains timing, dynamic and static power information (with respect to process variation) of each platform component, related to the executed workload as well as other relevant metrics like memory usage. User-defined module, port, process, and function names from the system specifi­cation (a,e) are preserved to ensure traceability to the input model of the executable specification. Simulation traces of each platform part are read into an analysis tool (p). Main tasks of this tool are extraction of activity- and power-relevant data of the different platform parts and to pre-process these data to be either graphically presented to the designer (q) or to be used by automatic exploration and optimization tool (r). The visualization engine (q) will take power and activity-data prepared by the analysis tool (p) and present this information to the designer. One possible visualization type is a platform power-breakdown in which the power contribution of all platform parts can be inspected. Platform evaluation and optimisation (r) is two-fold. On the one hand the user can constrain the overall platform selection, deduce further constrains on HW/SW separation, or identify power-consuming implementations and replace them with power-efficient ones. On the other hand, the automatic exploration and optimization tool is based on multi-objective optimization heuristics to efficiently navigate the overall design space defined in (t). Once obtained the design space definition, the exploration tool starts an optimization loop interacting with the rest of the COMPLEX design flow to find the optimal system configuration in terms of a user constrained target function. In the optimization loop, the DSE framework generates a new design space instance (s) to be automatically evaluated by the rest of the COMPLEX design flow, which returns the power and performance metrics (scalar values format) from (p). All information gained from the platform analysis and optimization phase will serve as input and feedback (s) to the next iteration of the platform refinement flow and thus will lead to an optimized executable specification of the overall system: Functional reimplementation improves or replaces the system specification in the MARTE PIM (a) or in SystemC (e), HW/SW partitioning/separation can be modified through changes in (c), runtime management can be optimized by providing a new DPM policy (m), different sets of cross-compiler optimization switches can be used in (j), different IP components can be selected or configured in (d, g), memory configuration and management can be modified via (a,c,d), and custom hardware synthesis constraints can be tuned in (i). The design space definition (t) represents the configurable system in terms of a discrete set of parameters to be automatically analysed by the exploration tool.

Last Updated ( Thursday, 27 May 2010 18:17 )  


Successful final review meeting
On Thursday, May 25th, the final COMPLEX review meeting has been held in Brussels.


Final public deliverables uploaded

All public COMPLEX deliverables are now available in the Deliverables section.


COMPLEX @ ISCUG'2013 conference
14-15 April, 2013 - Noida, India


Newsflash RSS Feed