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: