SYRF Project
Task 2: "Combination of Formalisms"
Abstract of deliverable 2.2
Back to the SYRF Home Page
Achieved Results:

Smooth Integration of Languages
The SYNCHRONY Workbench has gone through a major revision, embedding the technology of synchronous automata into an object-oriented framework, the synchronousEifel (sE) environment.

Objects in sE may be reactive meaning that a behaviour  component is specified in a synchronous formalism.  As usual objects encapsulate data operations. Reactive objects communicate via signals only, and are executed in parallel. Quite clearly, the design paradigm is very different to that of synchronous languages which use functional decomposition, and where the data space is global.

The present version of synchronousEifel is based on an Esterel-dialect and an extended version of Argos.  The next version (sE2.0) to be shipped by end of January will have Lustre as a declarative sublanguage.  The sE -programming environment offers a graphical editor for Argos and simulation environment for debugging.  It generates either C-code or hardware-formats such as Verilog or Blif.  Version sE2.0 should be able to generate DC.  The sE-environment at  present provides interfaces to verification with ctl, ptl, and synchronous observers. For sE2.0 an interface to NP-Tools will be provided.

sE has been applied to the SAAB case study (5). There are several publication on the semantics and ratrionale of the combination (2,3,6,7)

The combination of formalisms on the common format DC
Significant progress has been done in the implementation of tools allowing languages to be combined through the common format  DC.

A first version of the new  Lustre-V5 front-end, called lus2dc, is available. It performs the static verifications (types, clocks, unique definition, absence of dependence loops) and translate a
Lustre program into DC. This first version does not deal with arrays.

Imported nodes have been added to Lustre, to allow DC nodes coming from another language to be called from a Lustre program. The syntax of the declaration of an imported node only gives its interface, its body being replaced by the keyword ``imported''. In the dependence analysis, when an imported node is called, its output parameters are supposed not to instantly depend on its input parameter: this is a permissive option, the exact dependence analysis being only possible when the node body is known.

As a backend,  drac has been developed. It can translate a set of DC files either into a transformed DC file, or into a target language (presently C, C++, or Java).

Further, a scdc translation, which allows to compile Esterel programs in intermediate sc form to into the DC format. The resulting code can be combined at DC level with other software modules originated from other synchronous reactive formalisms.

The DC+ format, issued from european projects Synchron, Sacres and Syrf, serves as a common representation for programs (and properties) completely or partially described with synchronous languages such as SIGNAL, LUSTRE, ESTEREL, or STATECHARTS, and destined to verification and code generation tools. The DC+ representation of languages of the IEC1131 norm concerning industrial automatisms is under study. Different levels of DC+, or sub-formats, have been identified which support particular semantic concepts and the translations of synchronous languages.

A translator from SIGNAL to DC+ is available, a translator from DC+ to DC not yet.

The progress achieved this year concerning practical combination of synchronous formalisms on DC-level allows us to fully implement the SAAB case study in a mixed Lustre/Esterel version.

The compilation of mode automata into DC

Significant progress has been done, this year, about the compilation of ``Mode Automata'', a model that was defined last year. We investigate several solutions (see 4):


References and Publications:

  1. C2A-SYNCHRON.

  2. The common format of synchronous languages -- The declarative code DC.
    Technical report, Eureka-SYNCHRON Project, October 1995.
  3. L.Holenderski and A.Poigné.

  4. The Multi-Paradigm Synchronous Programming Language LEA.
    Proc. Int. Workshop on Formal Techniques for Hardware and Hardware-like Systems
    (associated with Mathematics of Program Construction conference), Marstrand, 1998
  5. L.Holenderski and A.Poigné.

  6. Synchronie Workbench.
    in: R.Berghammer, Y.Lakhnech (eds), Tools'98, Malente
    to appear: LNCS, 1998
  7. F.Maraninchi and Y.Rémond.

  8. Running modes in a data-flow language: Mode-automata and their implementation.
    Submitted for Publication, 1998.
  9. M.Müllerburg.

  10. Designing and Validating the SAAB example with sE.
    Draft,1998.
  11. A.Poigné, O.Maffeis, M.Morley, R.Budde and L.Holenderski.

  12. The Synchronous Approach to Designing Reactive Systems.
    in: Formal Methods in System design, 12, 163 187, 1998
  13. A.Poigné and L.Holenderski.

  14. On the Combination of Synchronous Languages.
    in:W.P.de Roever (ed), Workshop on Compositionality,
    Malente 1997, LNCS 1536,
  15. The synchronousEifel Site