An experiment in using Esterel Studio for modeling the control of mobile communication architectures

Hedi BOUFAIED, Arnaud CAVANIE, Bernard DION, Sylvan DISSOUBRAY Simulog

1

Laurent ARDITI, Gaël CLAVE Texas Instruments

2

Charles ANDRE 3

CNRS-I3S

Abstract This paper presents the Esterel language and the Esterel Studio modeling toolset that provide specification, simulation, verification and code generation for real time embedded systems. An application of the methods and tools for the simulation of an architecture developed at Texas Instruments for wireless communications systems is then given. Some conclusions are drawn from this experience.

1.

The Esterel Studio approach 1.1. The Esterel language and the SyncCharts notation

In this paper, we address the problem of the specification, verification and implementation of reactive systems. Such systems have to maintain a permanent and complex interaction with their environment. They include realtime systems (often embedded), communication protocols, man-machine interfaces, etc. In this context, interacting means receiving input signals and reacting by producing output signals. Another important characteristic of these systems is that they should always be ready to respond to the evolution of their environment and therefore react in due time, so that they have useful influence in return. Reactive systems modeling has proven difficult and error prone using traditional methods. This is why synchronous languages such as Esterel [1,2] (from École des Mines de Paris and INRIA) have been developed to model complex reactive behaviors. Esterel is based on a rigorous mathematical semantics so that it is possible to 1

Les Taissounières, HB2, Route des Dolines, 06560 Valbonne, France MS. 21, BP 5 , 06271 Villeneuve Loubet, France 3 41, boulevard Napoléon III, 06000, Nice, France 2

1

apply formal verification methods in order to track and eliminate defects, or to produce useful test scenarios. Esterel programs are compiled into very compact C code, if one wants to produce embedded software, or into VHDL code, if one wants to produce hardware circuits. It is therefore fitted to a HW/SW co-design approach. However, textual synchronous languages are mainly used by programmers, but control engineers and systems designers often prefer a graphical description of their system, especially in the early phases of specification and development. Several methods and tools exist, but these are not well suited to model reactive systems. Either because of some ambiguities or lack of rigorous semantics, it is quite impossible to apply formal verification techniques when using these graphical formalisms. For the same reasons, it is impossible to generate efficient target code with those tools. The SyncCharts notation [3] for specifying behavior and control was introduced by Charles ANDRE in 1997 to recover all these possibilities, adopting an unambiguous notation with strong semantics, determinism, and by following the synchronous model, which permits to benefit from the strength of the Esterel language, compiler and formal verification tools. SyncCharts permit a hierarchical description of state machines, with parallelism, communication and preemption as illustrated in Figure 1 below. At any level in the description, it is possible to insert Esterel textual program fragments; it is therefore a mixed graphic and textual notation. The Esterel Studio visual modeling toolset [4] was then created by SIMULOG, on the basis of this notation.

Figure 1: The SynchCharts notation

1.2. The Esterel Studio design process Esterel Studio provides an automated design flow from formal executable specifications up to production of embedded target code together with its test patterns. Therefore, it allows to deal effectively with late specification changes since code and test patterns can be automatically regenerated whenever specification is changed. This truly iterative design process is illustrated in the following Figure 2.

2

Refine Specifications

Formal Formal

Generated Generated Simulator Simulator

Specification Specification Generated Generated Test Test Scenarios Scenarios

Simulate

Hardware (VHDL, Verilog) Integration to EDA tools (Cadence, Synopsys)

Generated Generated Target Target Code Code

Software (C, C++, Java) Integration to UML and SDL tools (SDT)

Figure 2: The Esterel design process

Moreover, Esterel Studio allows to increase the safety of real time applications and to reduce testing time thanks 4 to the use of its formal verification tools based on a compact BDD internal representation of Esterel programs, which are themselves generated from SyncCharts specifications. A safety property can easily be described as an “observer”, which is an automaton whose role is to track unwanted situations. The verification tools will then tell you whether your system is safe or whether it found a bug. In the latter case, an event path leading to the problem is given as a scenario to play back in the simulator. Figure 3 gives an illustration of the verification process. The verification tools can also be used to produce scenarios for reaching any state or transition or any combination of those in the state machine.

CORRECTION CORRECTION

Graphical Specification

Interactive Simulation

BUG (SCENARIO)

Verification Tools

Unwanted Situation Observer

SAFE (NEVER (NEVER HAPPENS)

Figure 3: The formal verification process

4

Binary Decision Diagrams

3

2. The experiment at Texas Instruments 1.3. The context The experiment in using Esterel Studio at Texas Instruments takes place within a large project which is aimed at the development of a Digital Signal Processor (DSP) for wireless communication systems. Here, we briefly present the development methodology and why we have chosen to introduce the Esterel approach. Our project consists in developing a "MegaCell" which is a DSP core connected to a set of system modules such as bus controllers, peripheral controllers, internal memories, etc. One of the most important tasks in such a project is the validation problem. This is why the main idea has been to develop a software model of the system that will serve as a reference to validate the hardware model. The software model (C-model) is written in C/C++/Esterel, while the hardware one is written in VHDL. The validation method is simulation-based: a set of short assembly programs called test cases are developed. Each of these test cases exercises a given functionality of the system. When run on the reference C-model, inputs and outputs of the system are extracted at each clock cycle. These inputs are then used to stimulate the hardware model while the outputs serve as reference for comparison. Thus the hardware model is guaranteed to behave as the C-model does. Since the whole validation method is based on the software model, particular care is given to its design and development. We have chosen to use Esterel for programming some of the system modules. The advantages are of two kinds: • From a programming point of view: many of the system modules are complex control-intensive reactive systems: they are best described using high level constructs such as parallelism and preemption. The Esterel code for these modules are simpler, shorter, more readable and more maintainable than their former C versions. For short, they are closer to their specification and yet executable. • From a validation point of view: Esterel and Esterel Studio are based on a rigorous mathematical semantics in terms of Finite State Machines. This provides a metrics for measuring the coverage of our test suite: based on theoretically reachable states and actually reached states during simulation, we have developed a method to automatically generate new test cases in order to increase the state coverage of our system.

1.4. The MMI module We propose here an illustration of the modeling methodology. We present a module called “MMI” which is an interface between the CPU and the external memory. MMI, as described in Figure 4, is constituted of two main controllers: MMIP and MMID. They respectively manage the program and data requests. Because of the complexity of MMI and because the two controllers are almost independent of each other, we chose to model them as two separate Esterel modules. The only interaction is a mix of outputs, which is modeled in C.

MMI

EXTERNAL MEMORY

MMIP

MMID

CPU

4

Figure 4: The MMI architecture

Basically, MMI receives read or write requests from the CPU. It forwards the requests to the external memory, after ensuring it is free. It then waits for a ready from the memory and forwards it to the CPU. This is a simple behavior which is in reality much more complex because: • Several channels are connected between the CPU and MMI so that a priority arbitration has to be modeled. •

There is a pipeline in MMI and in the memory. That means the CPU can send several requests before waiting for a ready, and that MMI can send several requests to the memory before receiving a ready.

•

There are several configuration modes which change the MMI-memory communication protocole.

We present below the outline of the MMID model (see Figure 5 below) and we describe why and how parts of it have been written in textual Esterel, graphical SyncCharts, or in C code. MMID has five main input channels: CBUS and DBUS are read channels connected to the CPU, EBUS and FBUS are write channels connected to the CPU, and DMABUS is a read/write channel connected to a DMA module (Direct Memory Access controller). There is only one output channel to the external memory. We have decomposed MMID in several parts: CDBUS manages the CPU read requests, EFBUS manages the CPU write requests and DMABUS the read and write requests coming from the DMA. EXTBUS manages the communication with the external memory. As E and F requests may be acknowledged before having been sent to the memory, we also modeled a sub-module called WPBUS which is a kind of FIFO. All these modules are running in parallel.

MMID

EXTERNAL MEMORY

EXTBUS

WPBUS

CDBUS

DMABUS

D M A

CPU

EFBUS

Figure 4: The MMID module

We will not give further details about all the sub-modules but focus on EXTBUS which is representative of the different programming styles we use. EXTBUS is constantly tracking the requests which are sent to the external memory and the ready which have been received. Thus, it is able to notify other sub -modules when the memory is able to handle a new request. When one of EFBUS, CDBUS, DMABUS or WPBUS has a pending request, and EXTBUS has notified that a new request can be sent, the module forwards its pending request to EXTBUS. Then EXTBUS sends it to the memory and waits for the corresponding ready. Therefore, EXTBUS models three main functionalities: • a counter which tracks the number of externally pending requests, • a purely combinatorial part which handles an abort signal and sends output signals accordingly to the internal state, • two lower-level sub-modules which are the two slots managing the requests externally pending.

5

To illustrate the use of Esterel Studio, we have modeled the three sub-modules using the three main “macrostate” types. The counter that is often used in our systems has been described as a module in a separate file and is instantiated in a “Run module” macrostate. The combinatorial part has been described as a “textual macrostate” because combinatorial algorithms are easier to describe directly in Esterel. The modeling of the two slots are automata that are best described graphically. Thus, we use “graphical macrostates” to model them. We have designed MMIP and other modules using the same methodology. The benefits of a tool set like Esterel Studio over traditional modeling are numerous: • The models are much simpler and “elegant”. We found easier to design complex controllers in Esterel than in C. This is because of the possibility to express parallelism and pre-emption using primitive constructs. The same is true for the SyncChart notation. • The models are executable. Indeed, as SyncCharts descriptions are compiled as C code, the modules we have designed using this methodology are easily integrated in our whole DSP software model. However, we first noticed some performance issues: modules written in Esterel were much slower than modules directly written in C. But this is no more a real problem since optimization tools considerably reduce the size of the FSM and hence the execution time. Also, we have implemented a mechanism such that the models are executed only when necessary. We could then get an execution time in the same order as the one we get for hand-written modules. • The models are formal. Whereas many other modeling languages and tools, the semantics of Esterel has been formally defined. That means our models always behave deterministically, without any ambiguity. Therefore, we can consider the Esterel models as being specifications. The SyncCharts notation is also formal since each SyncChart block corresponds to an Esterel construct. We have seen above that the advantages of using the Esterel language for hardware modeling are obvious. Esterel Studio with its SyncCharts notation provides additional facilities: • Complex Finite State Machines (FSMs) are more naturally described using a graphical formalism. • Graphical hierarchy and the notion of macrostate has more impact than its textual form: it tends to structure the modeling process (top-down or bottom up). • Parallelism is easily expressed. •

Textual expression of behaviors is still possible. However, there is a lack of graphical constructs for expressing (instantaneous) combinatorial behaviors.

The fact that Esterel models are both formal and executable is crucial for our validation methodology: having executable models allows to analyze what functionalities are covered by a test suite (eg. The reached state set). Formal models can be formally analyzed to determine what could potentially be covered (eg. The reachable state set). We can then have an accurate measure of the coverage our test suite provides. We have proposed and set up a new validation methodology that exploits this information to automatically generate new tests in order to increase the coverage.

6

Figure 5: Memory Management described in Esterel Studio

3. Conclusions from this experiment Four Esterel modules are currently part of our software model: • The external memory interface (MMI), • •

2 kinds of internal memory wrappers : double access RAMs (DARAM) and single access RAMs (SARAM), A Direct Memory Access controller (DMA).

Other modules such as a peripheral controller are being developed and should soon be integrated. Some parts of some Esterel modules will also be redesigned using SyncCharts. This is the case for the DMA whose core is a complex hierarchical state machine that should be best designed using a graphical formalism. State based validation flow has been applied on MMI and DARAM: • For MMI: the data part module (MMID) is unmanageable using current tools: state space computation leads to more 3 million states. Hierarchical optimization techniques (currently under development at École des Mines) should lead to more realistic results. With MMIP, our Esterel based method has led to a set of input patterns. New test cases have been manually developed out of these patterns making state coverage increase from 35% to 73%. • For DARAM: new test cases (assembly language) have been automatically generated leading to a 100% state coverage of this module. The initial test suite representing 45000 test cases could only reach a coverage of 33%.

References [1] Gérard BERRY, The Esterel V5 Language Primer, École des Mines de Paris and INRIA, April 1999 [2] http://www-sop.inria.fr/meije/esterel [3] Charles ANDRE, Representation and Analysis of Reactive Behaviors : A Synchronous Approach, CESA’96, IEEE-SMC, Lille, France, July 1996

7

[4] http://www.simulog.fr/esterelstudio

8