Esterel Technologies
Address Twins 1, 679 Av Julien Lefèbvre
Zip Code F-06270
City Villeneuve-Loubet
Country France
Phone +33 (0) 4 92 02 40 40
Fax +33 (0) 4 92 02 40 64

Corporate Profil

Esterel Technologies' product Esterel Studio provides the designers with high-level design tools based on the Esterel language and the SyncCharts graphical formalism. Formal analysis tools include model checking, equivalence checking,automatic test generation, Boolean optimization, and causality analysis. Esterel Technologies owns a leading-edge BDD-based technology particularly tuned for Esterel Studio. The company plans to enhance and extend its formal verification and analysis to handle the next evolutions of the Esterel Studio formalisms, and the constant increasing complexity of customers' designs, using all the available technology.

Test-bench Generator Activity

  1. Motivation
  2. Methods / Languages
  3. Esterel Studio
  4. Presentation
  5. User manual
  6. Example
  7. Download



Test-bench generator became a new feature of the industrial application Esterel Studio produced by Esterel Technologies. The basic aim is to give user the way to simulate their design written in several ES compliant target languages devoted to either embedded system on the chip or synthesis. Hence, designer may, on a side, specifying the architecture througth ES, and on an other side keeping their hand written design. The strength of a such automatic test-bench generator is generate a common scenario file into a selected target language which can be understanding by the both applications. Stimuli are the same in the both case, impliing the predictible same outputs monitoring.

Methods / Languages


Analysed requirements, produced detailed design specifications, designed using UML over a V life cycle. Implemented over 30,000 lines, in C/C++ using design patterns ensuring quality code easier to integrate and support. The architecture is based uppon traditionnal compilers techniques from flex/bison for the front-end to code generation.

Esterel Studio

test-bench generator settings runs test-bench generator

Test-bench generator has become a new feature of the industrial application Esterel Studio produced by Esterel Technologies. The prime purpose is to give the user a way to simulate their design written in one of the several ES compliant target languages devoted to either embedded system on the chip or synthesis. Hence, the designer may specify the architecture througth ES whilst keeping a hand written design. The main asset of a such an automatic test-bench generator is the generation a common scenario file which can be compiled into a selected target language understood by the both applications. Stimuli are the same in the both cases, implying the predictible same outputs monitoring.


HDL Test-bench Generator Overview Tests presentation top

The presentation is split into 6 parts. The first will present the main application fields of the test-bench generator. The second will explain how to use the application. The third will resume the main used schemas. The fourth will introduce the applicability of test bench generation in the validation process. The fifth will explain the principle features of the product and provide a practical demonstration of each one.

In a nutshell, test-benches test designs. The only compliant scenario description language is ESI/ESO. An important goal is to make it compatible with the ES simulation engine and other user hand-written designs. The designer may therefore specify a model with ES, referred to as the 'golden model', through ES formal tools such as its BDD based model checker or states coverage. A States coverage scenario is converted into an ESI format, then the test-bench generator focuses on translating it into an equivalent scenario written in a target language such as VHDL, Verilog, ... The user design specified in one of those HDL languages could be compared with the same stimuli as the ones applyed to the 'golden model'. The second interesting point in test generation concerns the multiple proposition of target languages. Designers are no longer restricted to any target language. Besides, FSM may be tested at simulation level with ES, in embedded-C, in HDL given the same output log files. Target languages are relegated to middleware, the user need only be concerned about the ESI scenario file and ESO log files.

Application Run Overview Batch Application presentation top

How does the Test-bench generator integrate with ES There are two modes offered to the user: ES or batch mode. The former is more flexible since most of the options are available. The latter is easier to use because little is required of the user bar clicking on an icon on the screen and perhaps the occasional parameter adjustment via the user settings panel.

The application is a stand-alone product, that is it can be executed alone without all of the ES environement. It is targetted at many different OS architectures such as Sun, Sparc, Windows, Irix and Linux, the application being separately compiled for each one.The user manual covers this aspect exhaustively.

Esterel Studio Test-bench Generator Use Overview presentation top

The simplest way to use the Test-bench generator is without question through ES environement. Options settings are restricted, however, but an advanced options entry allows experienced user a means of feeding the application with those options.

We will now explain how to use the Test-bench generator. Firstly we will present the synopsis, and after that an overview of the ideal method to generate a test-bench.

Synopsis Esterel Module Compiling presentation top

Here, the application synopsis takes an esterel file, an ESI scenario file and a esterel toplevel module as mandatory inputs. Several options detailed in user manual are applyed on the generator to modify its behavior and generate an output scenario file. Selecting a target language, the application basically transforms the same stimuli as those found in the ESI file into the aforementionned language. At compile time lexical and syntaxical errors in the inputs scenarii cause the application to crash, producing messages. At run time, the test-bench is able to generate a log file that traces of the execution in a ESI-like format: ESO. Finally, a few user files are required to define user procedures, functions and data types in order to compile each target language.

To turn an user designed esterel model into a runnable application, we must begin by compiling the esterel files into a target language. The structured esterel programm is translated into a syntactically equivalent FSM ,then generated into VHDL, Verilog, C or C++.

Test-bench Synthesis Run Embedded Simulation presentation top

Then from an ESI file, an equivalent scenario is produced into VHDL, Verilog, C or C++. Of course the module that originates from the ES compilation process has to be compatible with the ESI scenario compiled target language.

At this stage we have compiled an esterel file and an esi scenario file into a specific target language. Hence, we are now able to link them together in order to obtain an executable file. At run time, this application will generate a trace log file in ESO format. ESO is the same format as the ESI but with comments which are run time generated outputs produced by the FSM. For example if in an ESI file an input A is emitted and according to the 'golden model' an output O is awaited, then the ESO log file contains A followed by the reaction function call and a comment: O. According to the user design, O may not be emitted by its own FSM, then this mismatch ensures that the hand-written model fails and must be reviewed.

Test-bench in Processes Validation - Overview User Scenarii in Batch Mode presentation top

We have observed how to use the application and how trivial it can be to compare log files with expected emitted outputs. We will overview the application of such generated test-benches to the validation processes.

A user could run several hand written tests as automatic scripts uppon a base. Generated ESO files are at run time generated for future tests purpose.

Automatic Generation User FSM Validation: Diff presentation top

Typically, a user would use the ES GUI with the Test-bench generator icon to automatically generate a test-bench. The esterel design is mapped into a selected language, and with the state coverage option set, the user is ensured that all states will be visited. The inputs stimuli is recorded to a file in ESI format. As a by-product of this process, a test-bench will be generated from this states coverage scenario into the same selected target language. At compile time on a target architecture, ESO file will log all statements and will contain the outputs. Consider how difficult it could be to collect all these outputs signals and make them match with ones produced by a 'golden model'.

Then we could on one hand run the scenario with a golden model and save all these log files. Then on the other, scenario providing same stimuli will applyed on user FSM and then they should be automatically compared with a differentiate method for example.

User FSM Validation: Automatic Assertions Features Overview presentation top

Automatic assertions provide the user with a clean mechanism to make their FSM terminate immediately, should an inappropriate output appear, rather than requiring a later comparison with the golden model ESO log file produced under ES. Hence, the golden model is run over a scenario, generating an ESO file. The test-bench generator will take as ESI input the ESO file. The automatic assertions option enables the parsing of ESO output signal comments and asserts what outputs should or shouldn't be emitted for each tick. After that, the user will typically run his/her hand written scenario to generate an ESO log file and then at run-time log errors if awaited outputs mismatch.

We will present some features of the application. We have shown that several target language are available but other features were required. For example, a new statement in ESI format had to be added. At least a couple of different ESO formats are supported. And futhermore, what are the others efficient strengths of such a test-bench generator.

Scenarii in Target Languages User Assertions presentation top

We have seen that several target languages are presently supported. Furthermore, we ensure that generated code is also readable thanks to indentation, comments, line feeds, ...

New instructions have been added to declare user assertions as invariants. An invariant is similar to an assertion but it is evaluated for each tick. Assertions can be applied on both pure or valuated signals, sensors and values. They are typed implying user functions definitions.With options, it is possible to enable or disable assertions or piece of them like these which are based upon usersdefined data types.

ESO formats Specification Level in Life Cycle presentation top

A couple of ESO formats are available: one is supported by the ES engine layered over coresim and the other is used by a SignalRecord library designed for embedded outputs monitoring. Both could be generated by the test-bench generator in VHDL or Verilog. But C and C++ target languages cannot support the coresim ESO-like format because they focus on embedded code and have to be linked with the SignalRecord library.

Generated test-benches could take place in a V life cycle environement. Functional specifications define also functionnal tests written in ESI. Then they could be simultaneously translated into target languages and be freezed, thus ensuring quality in he following tests by banning hand user rewrites after design specifications. However, the quantity of test cases may be huge, and such compiled test-benches may become massive and scale poorly. Then, another format produced by the test-bench generator should be meant. With user test case, such a test-bench are more efficient because they are thin and should be reviewed or user hand modified in target language.

ESI syntax checker Compile Time Checker presentation top

We have seen that generated test-bench could be written into VHDL, Verilog, C or C++. An other language was implemented: ESI/ESO ensuring good indentation. Moreover types and data are checked producing messages.

Test-bench generator is not merely a translator taking data and generating it into a language. At compile-time signals, data, ... are checked or cross-checked via an abstract syntax tree. The AST, once analysed, is dumped into a file with the syntactically syntax chosen by user basically called target language. The internal structure has been inspired by modern compiler architecture from the front-end written in flex/bison to AST checking and code generation. It is therefore possible to apply code factorization such as loops. For example, if a same record appears in the ESI file, it could be detected and a loop could be generated in the selected target language. However, the generated test-bench should no longer be considered as the same scenario as the one originally written in ESI/ESO format.

Example An Esterel Module presentation top

Using a simple example, one that is well-known by esterel users: ABRO. We will first show the esterel module and then a simple scenario to explain how to utilize assertions.

We declare a blackbox called ABRO. The interface to the environement declares three pure inputs A, B and R. The can either be present or absent. Also output O which could also be present or absent depending on internal behavior. Finally the behavior itself: the module waits forever for both A and B signals. Finally, when both are received, it emits an O signal and then pauses until an R arrives which could be seen as a reset input signal. If for example, A was set, the system then waits for a B , but if R is present the behavior resets.

An ESI Scenario File presentation top

Here is the ESI file beginning with all signals reset and initialize teh FSM. An assertion ensures that A can be emitted but O must not. The severity level is note which represents a breakpoint in the scenario code. After A is set and the reaction function calls. At run time, when the ESO log file is generated, we should see no error. However, if O had been emitted then an error should occured with note status. The reaction function call is an other time called followed by a new assertions. It asserts that O is emmited. If this is not the case, an error occurs with a failure status. The user implements in C or VHDL such requirements. If its FSM does not emit O then the error shows that its FSM is not equivalent than the golden model.


user manual Download the User Manual in PDF Download the User Manual in PostScript Download the User Manual in HTML
example (PDF) Download the zipped example

top home contact