SYRF Project

Task 4/5.2: "Integrating synchrony & asynchrony: distributed code generation"

Foreword:

Integrating synchrony & asynchrony is a major issue for the practical use of the synchronous technology, this is why a WP is devoted to it. This WP and the present task summary is presented according to the new organization for the former two WP 4 and 5. Accordingly, a task called distributed code generation was introduced in this reorganization, and we report its progresses now.

Approach:

Here we build on the fundamental results of Task 4/5.1. The following methodology is advocated for distributed code generation:

We are given a synchronous functional specification.
A deployment is specified for it on a given distributed architecture. This architecture can be ``physically'' distributed (e.g., a network of DSP's), or alternatively it can be a set of tasks to be controlled by some real-time OS or kernel. The following is assumed about the corresponding communication medium:

messages shall not be lost;
for each given flow, the total ordering of successive occurrences shall be preserved.

These are the conditions required for our results of Task 4/5.1 to apply. A library of procedures is available, for calling appropriate services of the communication layer; developing such a library for a given real-time kernel is generally of low cost.

This item is not required, but can be useful for guaranteing the satisfaction of non functional specifications: a behavioural description of communication media is available (e.g., mailbox, bounded fifo, shared variable,...) in the form of a, typically nondeterministic, synchronous model.

The following is constructed as a result of distributed code generation, also viewed as architecture generation:

Sequential object code is generated for each task. If subsequent reuse as object code is wished for each task, then it must be the case, for the task in consideration, that no input communication with the environment is needed during the reaction, i.e., read_input/compute_reaction/emit_outputs is a valid execution scheme whatever the environment does.
Tasks are distributed onto processors : processors can be physically distributed, or can be OS threads. Tasks are scheduled by an automatically generated scheduler. The scheduler captures control and scheduling constraints resulting from the causality analysis of the source specification.
In the sequel, a ``processor'' shall denote an atom of our distributed architecture, it shall also refer to the program it executes. In order to guarantee semantic preserving, we need to make sure that our set of processors constitute an isochronous family, and that each processor is endochronous. This is achieved by automatically generating suitable protocols in the form of additional synchronous programs added to each processor.
Architecture profiling and non functional (partial) validation can be achieved by considering jointly:

the task schedulers,
the communication protocols
the models of communication media,

and generating for them real-time behavioral models, say, in the form studied in task Task 4/5.3.

Achieved Results:

The Signal compiler as been rearchitectured, and new modules have been written. Each module provides a particular service, e.g., for a given specification compute its {clock,causality} abstraction, or produce a task scheduler, generate code for a task, equip a sunchronous module with its proper interface for further desynchronisation, etc. These modules equivalently apply to the DC+ format for synchronous languages.

Publications: the detailed method is found in ref. 1, a sketchy description is found in ref. 2.

T. Gautier and P. Le Guernic
Code generation in the SACRES project,
Proceedings of the Safety-critical Systems Symposium (SSS '99),
Huntingdon, 9th-11th February 1999, to appear in Springer V. LNCS.
A. Benveniste
Safety Critical Embedded Systems Design: the SACRES approach,
3 hour course given at FTRTFT'98 school on the whole SACRES project,
manuscript available.