Embedded System designers need tools to help them decrease time-to-market, establish economic feasibility, early detect risk sources, build realistic-complete virtual prototypes, and conduct error-free designs, whilst still allowing them to describe the system with the use of abstract models. With these needs in mind, HiLeS was presented at LAAS by Jiménez (2000) as the result of his PhD. HiLeS provided a tool that allows designers and engineers to produce a high level design defining the functional decomposition, hierarchy and structure of the system. HiLeS proposal is based on a formalism based on Petri Nets and a global system design methodology. HiLeS tools integrated novel features as a high-level graphic semantic, a formal representation of functional states and a partial automatic generation of VHDL-AMS code. HiLeS provided design functionality validation by execution of the generated code on SystemVision and behavioral validation by the evaluation of Petri Nets using Tina.

Petri Nets

Petri net is a mathematical language which can be used, among other things, to model discrete events systems. Petri nets' graphical notation allow representation of process in which choice, iteration, and concurrent execution can be defined. This formalism is currently used to model and verify designs in different domains. Additionally, there have been extensions to the language to represent the continuous behavior in order to model systems in continuous domains and also to represent hierarchy. An example are Differential Predicate Transition Petri Nets (DPT-PN), where each token is associated to a variable and each place to differential equation system.

HiLeS Formalism

High Level Specification (HiLeS) formalism consists of a language and a methodology. The language is an extension to the Petri nets that incorporates continuous behavior and hierarchy. The methodology is intended to support embedded system design. Additionally, HiLeS defines the mapping rules to represent a HiLeS model in a hardware description languages. This enables designers to build virtual prototypes that allow technological independent analysis and operational verifications, with both formal and simulation verification of specifications and requirements.

The HiLeS formalism was created to support designing processes with a formal behavioral model and to integrate novel features as a high level graphic semantic, a formal representation of functional states and compatibility with multidisciplinary representation languages for digital, analog and mixed signal descriptions. With HiLeS it is possible to describe asynchronous and concurrent behaviors, and either time, event, or mixed driven dynamics. Figure 1 presents the elements of the HiLeS language.

Figure 1. HiLeS Language elements

Control Model

The control model of a system described by HiLeS is based on ordinary Temporary Petri Nets (Figure 1 a). The Petri net represents the execution of control commands and the blocks synchronization. The graph is constructed with two types of nodes: the places and transitions, two places can’t be directly linked and two transitions neither. All the transitions got a triggering time of zero or superior. The Petri net arcs are represented by dashed arrows.

Structural and Atomic models

The structural blocks are represented by rectangles (Figure 1 b) and allow the structural and hierarchical decomposition of the system. They admit all input/output channel types. Structural blocks can contain other structural or atomic blocks and a hierarchical control net. The Atomic blocks, or Functional blocks,  are represented by round corner rectangles (Figure 1 c). and describe the system continuous behavior in the form of differential, algebraic or logic equations. Atomic blocks don’t have hierarchical properties.

The channels

The blocks or models and the control net are linked with channels. The channels transport two signals types: continuous (Figure  2 a) and discrete (Figure 2 b). The nature of the signal depends on the in/out ports nature (electronic, mechanic, thermal, chemical, etc.)

Figure 2. Channel types defined by HiLeS.
 
We consider the Petri net arcs (Figure 2 c) as a particular type of discrete channel that indicates various things:

• The flow of the token at the control net
• An atomic block trigger signal, i.e. initiate execution
• An atomic block activities acknowledgement, i.e. signal end of execution
• Structural blocks control net signal exchanging, i.e. hierarchical flow of tokens

Services and Ports

The services and ports are the input/output points of blocks (Figure 3). They contain a nature or a type depending on the type of channel connected to them

 
Figure 3. Services and ports.
 
The services are the environment exchange  points of a functional description. The ports represent the exchanges of a black box on a given environment. A port of a Structural Block is a equivalent to a service inside the block.

References

• Jiménez, F. (2000). Specification et Conception de Micro-systemes Bases sur des Circuits Asynchrones. Phd Thesis, Institut National des Sciences Appliquees (Toulouse, Fra), LAAS-CNRS (Toulouse, Fra), Uniandes (Bogota, Col).