Esterel Program Research Articles

Detection of harmful schizophrenic statements in esterel

In imperative synchronous languages, a statement is called schizophrenic if it is executed more than once in a single clock. When a schizophrenic statement is translated into a circuit, the circuit can behave abnormally because of the multiple executions. To solve the problems caused by schizophrenic statements, compilers duplicate the statements to avoid multiple executions. Esterel is an imperative synchronous language. Schizophrenic statements in Esterel are considered to occur due to the instantaneous reentrance of local signal declarations or parallel statements. However, if the corresponding circuit of a schizophrenic statement behaves normally, it is harmless and thus curing is not necessary. In this paper, we identify the conditions under which a schizophrenic statement of the Esterel program must be cured during circuit translation. We also propose an algorithm to detect schizophrenic statements that have to be cured on the control flow graphs (CFGs) of source codes. Our algorithm detects all schizophrenic statements that have to be cured and results in fewer false alarms on the benchmark programs used in the previous work. It is simple and based on the CFG of a program, implying that it can be merged into existing compilers easily.

Specification and verification of time requirements with CCSL and Esterel

The UML Profile for Modeling and Analysis of Real-Time and Embedded (MARTE) systems has recently been adopted by the OMG. Its Time Model extends the informal and simplistic Simple Time package proposed by UML2 and offers a broad range of capabilities required to model real-time systems including discrete/dense and chronometric/logical time. MARTE OMG specification introduces a Time Structure inspired by Time models of the concurrency theory and proposes a new clock constraint specification language (CCSL) to specify, within the context of UML, logical and chronometric time constraints. This paper introduces the formal semantics of a fundamental subset of CCSL clock constraints and proposes a process to use CCSL both as a high-level specification language for UML models and as a golden model to verify the conformance of implementations with the specification. A digital filtering video application is used as a running example to support the discussion. The application is first formally specified with CCSL and the specification is refined based on feedback from our CCSL-dedicated simulator. In a second phase, an Esterel program of the application is considered. This program is instrumented with observers derived from the CCSL specification. Esterel Studio formal verification facilities are then used to check the conformity of the Esterel implementation with the CCSL specification. A specific library of Esterel observers has been built for this purpose.

STARPro — A new multithreaded direct execution platform for Esterel

Esterel programs have traditionally been compiled to software code for general purpose processors or to hardware netlists. This paper, instead, proposes a reactive processor for the direct execution of Esterel. This intermediate approach offers the same flexibility as software compilation, while at the same time, providing much better code size and execution time. The proposed architecture, called STARPro, is a pipelined, multithreaded, reactive processor that provides native support for the direct execution of Esterel. STARPro manages Esterel threads and their scheduling, and also features a hardware preemption unit to assist the handling of the abort constructs in Esterel. In addition to the proposed architecture, we have also developed a new intermediate format called UCCFGsd (unrolled concurrent control-flow graph with surface and depth) to represent the structure of an Esterel program in our compiler. UCCFGsd closely resembles the Esterel source, and it has also been designed with Esterel hardware support in mind, allowing a straight forward translation into STARPro assembly instructions. We have compared the performance of STARPro against a recent reactive architecture and found an average of 37% speed-up in worst-case reaction times, and 38% in average-case reaction times.

Worst Case Reaction Time Analysis of Concurrent Reactive Programs

Reactive programs have to react continuously to their inputs. Here the time needed to react with the according output is important. While the synchrony hypothesis takes the view that the program is infinitely fast, real computations take time. Similar to the traditional Worst Case Execution Time (WCET), the Worst Case Reaction Time (WCRT) of a program determines the maximal time for one reaction.In this paper, we present an algorithm to determine the WCRT of a program written in the synchronous language Esterel. This value gives an upper bound for the execution time when the program is executed on a reactive processor. Specifically, we consider the execution of the Esterel program on the Kiel Esterel Processor (KEP), a reactive processor that can execute Esterel-like instructions. Here the WCRT directly determines an upper bound on the instruction cycles per logical tick. The WCRT also gives a guideline for the execution time when the Esterel program is compiled to software by a simulation-based approach.We have implemented the WCRT analysis algorithm as part of an Esterel compiler for the Kiel Esterel Processor (KEP) and have measured an accuracy of analysis results of about 22% on average.

Removing Cycles in Esterel Programs

Esterel belongs to the family of synchronous programming languages, which are affected by cyclic signal dependencies. This prohibits a static scheduling, limiting the choice of available compilation techniques for programs with such cycles. This work proposes an algorithm that, given a constructive synchronous Esterel program, performs a semantics-preserving source code level transformation that removes cyclic signal dependencies. The transformation is divided into two parts: detection of cycles and iterative resolution of these cycles. It is based on the replacement of cycle signals by a signal expression involving no other cycle signals, thereby breaking the cycle. This transformation of cyclic Esterel programs enables the use of efficient compilation techniques, which are only available for acyclic programs. Furthermore, experiments indicate that the code transformation can even improve code quality produced by compilers that can already handle cyclic programs.

Synthesizing safe state machines from Esterel

Esterel and Safe State Machines (SSMs) are synchronous languages dedicated to the modeling of embedded reactive systems. While Esterel is a textual language, SSMs are based on the graphical Statecharts formalism. Statecharts are often more intuitive to understand than their textual counterpart, and their animated simulation can help to visualize subtle behaviors of a program. However, in terms of editing speed, revision management, and meta-modeling, the textual nature of Esterel is advantageous. We present an approach to transform Esterel v5 programs into equivalent SSMs. This permits a design flow where the designer develops a system at the Esterel level, but uses a graphical browser and simulator to inspect and validate the system under development.We synthesize SSMs in two phases. The first phase transforms an Esterel program into an equivalent SSM, using a structural translation that results in correct, but typically not very compact SSMs. The second phase iteratively applies optimization rules that aim to reduce the number of states, transitions and hierarchy levels to enhance readability of the SSM. As it turned out, this optimization is also useful for the traditional, manual design of SSMs. The complete transformation has been implemented in a prototypical modeling environment, which allows to demonstrate the practicality of this approach and the compactness of the generated SSMs.

PERTS: an environment for specification and verification of reactive systems

Abstract In this paper, we describe the design and implementation of an environment for specification, analysis and verification of reactive systems. The environment allows the user to develop specification in the graphical formalism of Statecharts and analyze them using a simulation tool. A built-in translator tool translates the specification into an Esterel program for the purpose of carrying out verification. Through such an approach, we have been able to integrate the powerful graphical formalism of Statecharts, which is very appealing to engineers, and the power of the formal verification environment of Esterel. Since we translate Statecharts, which can be non-deterministic, to Esterel programs, which are fully deterministic, the system overcomes the non-determinism in the specifications by enforcing priority. The behavior of Esterel programs generated by the translator follow Harel and Naamad's ‘step’ semantics. In the paper, we describe the main components of the PERTS environment and the principles underlying the translation and illustrate the use of the system for specification and verification using an example.

BDL: a specialized language for per-object reactive control

The problem of describing the concurrent behavior of objects in object oriented languages is addressed. The approach taken is to let methods be the behavior units whose synchronization is controlled separate from their specification. Our proposal is a domain-specific language called BDL for expressing constraints on this control and actually implementing its enforcement. We propose a model where each object includes a so-called "execution controller", programmed in BDL. This separates cleanly the concepts of what the methods do, the object processes, from the circumstances in which they are allowed to do it, the control. The object controller ensures that scheduling constraints between the object's methods are met. Aggregate objects can be controlled in terms of their components. This language has a convenient formal base. Thus, using BDL expressions, behavioral properties of objects or groups of interesting objects can be verified. Our approach allows, for example, deadlock detection or verification of safety properties, while maintaining a reasonable code size for the running controller. A compiler from BDL has been implemented, automatically generating controller code in an Esterel program, i.e., in a reactive programming language. From this code, the Esterel compiler, in turn, generates an automaton on which verifications are done. Then this automaton is translated into a C code to be executed. This multistage process typifies the method for successful use of a domain-specific language. This also allows high level concurrent programming.

Hard Real-Time System Implementation on a Microcontroller

This paper addresses the issue of the design of reactive applications subject to hard temporal constraints. We advocate the use of the synchronous language ESTEREL for the design of such applications. The target machine is a real-time microcontroller (RTX2000 from Harris). This paper deals with the automatic translation from an ESTEREL program down to microcontroller code, and the validation (both logical and temporal) of the implementation.

Incremental development of an HDLC entity in Esterel

Abstract Esterel is a new parallel programming language based on a model of perfectly synchronous parallelism and communication. Because this model is naturally deterministic, it provides an excellent framework for the modular decomposition of programs that engage in complex patterns of deterministic interaction, such as protocol entities. Furthermore, because the Esterel compiler performs all the scheduling and synchronization at compile-time, modular with lots of subprocesses and internal communication can be just as efficient as monolithic sequential state machines. A restricted model of an HDLC entity is used to illustrate the new programming style that is made possible by these features. An Esterel program is developed in several steps, starting from a simple restricted case, and then adding features and complexity. The emphasis is first on design as we develop a program architecture that captures the basic procedures of the protocol in independent modules; then it shifts to maintenance as we add new features into the initial architecture by plugging new modules into the base program.