Home Tools HIFSuite/Stateflow


The code generation from Stateflow descriptions is based on the HIFSuite tool. HIFSuite is based on an intermediate language, namely the Heterogeneous Intermediate Format (HIF) and a set of front-end and back-end tools to map other languages to and from HIF.

Internally to HIFSuite, the correctness of generated code is guaranteed by implementing a formal model of computation, named UNIVERCM. The subsequent design flow, incorporating the HIFSuite, is reported in Figure 1 and it is composed by the following steps:

1) Translation of input MDL description into HIF/UNIVERCM by using a front-end translator, namely sf2hif. This is the most critical phase, since it requires a semantic mapping between Stateflow models and UNIVERCM models.

2) Translation of HIF/ UNIVERCM description into SystemC or C++, by using a single back-end translator, namely hif2cpp. During this phase, the back end translator calls an algorithm, implemented by using the visitor design pattern, to refine the HIF description into either SystemC or C++ description.

Figure 1: TheSystemC/C++ code generation flow, exploiting HIF/univerCM format.

To better clarify the Stateflow-to-UNIVERCM mapping issues, the main features of UNIVERCM are here reported.

UNIVERCM is a computational model which allows representing heterogeneous systems as Finite State Automata (FSA). For example, it allows to model in uniform way software, digital hardware, and continuous components like analogue hardware or the environment. UNIVERCM allows discrete evolution on transitions, while continuous is represented by differential equations computed into states. UNIVERCM supports priorities between states and transitions, in order to represent more concisely complex behaviours. Some important features are:

  • Variables: can be of discrete, continuous or wire type. In this work, only discrete variables have been used.
  • Labels: are conceptually similar to events, since they do not have any associated value. They can be used to synchronize parallel automata.
  • Transitions: can have guard to allow they crossing, and actions. Guards can involve both labels (enabling labels) and variables (enabling conditions). Actions can involve both label generation (updating labels) and variable assignments (updating variables).
  • Automaton: different automata are always considered to evolving in parallel. Thus, eventual synchronization must be explicitly represented (e.g. by using variables and labels). Automata can be used to represent a variety of different components, like SW threads, SW processes, HDL processes and functions.

Conversely to many other computational models, UNIVERCM has not been designed for top-down design methodologies, like Model Based Design. Instead, it is focused on bottom-up design flows. Therefore, it can be used as a unifying model for different languages. For example, reuse of IPs written in different HDLs can be implemented by mapping corresponding languages to univerCM, and then mapping the UNIVERCM representation to the preferred output HDL.


Last Updated ( Saturday, 18 May 2013 21:47 )  


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