A Synchronous Language at Work: The Story of Lustre

Gnesi, Stefania; Margaria, Tiziana

doi:10.1002/9781118459898.ch2

Cited by 25 publications

(30 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Multi-clocked systems can also be described by the synchronous language Lustre [3,47]. Each Lustre program basically consists of a set of equations over data streams.…”

Section: Lustre and Signalmentioning

confidence: 99%

Clock refinement in imperative synchronous languages

2013

View full text Add to dashboard Cite

The synchronous model of computation divides the program execution into a sequence of logical steps. On the one hand, this view simplifies many analyses and synthesis procedures, but on the other hand, it imposes restrictions on the modeling and optimization of systems. In this article, we introduce refined clocks in imperative synchronous languages to overcome these restrictions while still preserving important properties of the basic model. We first present the idea in detail and motivate various design decisions with respect to the language extension. Then, we sketch all the adaptations needed in the design flow to support refined clocks. Reviewhave been proposed for the development of safety-critical embedded systems. They are based on a convenient programming model, which allows one to generate deterministic single-threaded code from multi-threaded synchronous programs. Thus, synchronous programs can directly be executed on simple micro-controllers without having the need to use complex operating systems. In addition, synchronous programs can straightforwardly be translated to hardware circuits [4][5][6], which makes synchronous languages attractive for the use in hardware-software co-design. Furthermore, the concise formal semantics of synchronous languages is the basis for formal verification of the correctness of the programs as well as of the used compilers [7][8][9][10]. Finally, since macro steps consist of only finitely many micro steps whose number is known at compile-time, one can determine tight bounds on the reaction time by a simplified worst-case execution time analysis [11][12][13][14].All these advantages are due to the underlying synchronous model of computation [1], which divides the execution of programs into micro and macro steps, where variables change synchronously only between macro steps and remain constant during micro steps. The partitioning into micro and macro steps is explicitly *Correspondence: gemuende@cs.uni-kl.de Department of Computer Science, University of Kaiserslautern, Kaiserslautern, Germany given by the programmer, and the micro steps are executed in a causal ordering so that there are no read-afterwrite conflicts [7,15]. As a consequence, all threads of a program run in lockstep: they execute the micro steps of their current macro steps in the common global variable environment, and therefore automatically synchronize at the end of the macro step.Obviously, the synchronous model of computation enforces deterministic concurrency, which has many advantages in system design, e.g., to avoid Heisenbugs [16] and to allow compile-time analyses, e.g., on WCET. At the same time, however, it imposes tight restrictions on modeling possibilities, since there is no means to express the independence of threads in certain program locations. This phenomenon-where synchronous lockstep execution of threads is enforced even though it is not necessary-is often referred to as over-synchronization. Over-synchronization occurs quite frequently, since the input signals of a system us...

show abstract

“…Multi-clocked systems can also be described by the synchronous language Lustre [3,47]. Each Lustre program basically consists of a set of equations over data streams.…”

Section: Lustre and Signalmentioning

confidence: 99%

Clock refinement in imperative synchronous languages

2013

View full text Add to dashboard Cite

show abstract

“…We are therefore interested in a modular verification. Of course, modular verification has to follow the semantics of modules and module calls, and this is defined differently for these languages: While functional languages like Lustre [17] consider modules as functions without side effects and essentially assume that all modules are started in parallel to all other modules, languages like Esterel [11] and Quartz [12] allow module calls in arbitrary statements. In these languages, modules are declared with input and output parameters (variables) so that the body statement of the module is only allowed to read its input variables and to write to its output variables.…”

Section: Introductionmentioning

confidence: 99%

Modular Verification of Synchronous Programs

Gesell

Schneider

2013

2013 13th International Conference on Application of Concurrency to System Design

View full text Add to dashboard Cite

In this paper, we develop an approach to the modular verification of synchronous programs. To this end, we have to solve two major problems: First, if a synchronous module is verified without its later context, outputs may not be completely determined (since the calling module may add further actions on the outputs of the called module). It is not difficult to see that the open system obtained by modular compilation simulates the closed one obtained by the linker, and therefore, we can preserve all universal temporal properties. Second, a module call may replace the formal input parameters by expressions which corresponds with a substitution of variables in the symbolic transition relation. In particular, this affects the starting point and potential preemption conditions of the module and can therefore dramatically affect the behavior of the module. For this reason, we have to modify the temporal specifications accordingly. We prove a preservation result for this transformation that defines a simulation preorder modulo substitution. Our results finally determine a proof rule for the verification of module calls in imperative synchronous programs.

show abstract

“…Languages such as Esterel [1], Quartz [2] or Lustre [3] are based on the synchrony hypothesis. Synchrony is a logical abstraction of time which greatly facilitates verification and synthesis of safety-critical embedded systems.…”

Section: Introductionmentioning

confidence: 99%

Constructive polychronous systems

Talpin¹,

Brandt²,

Gemünde³

et al. 2014

Science of Computer Programming

View full text Add to dashboard Cite

Abstract. The synchronous paradigm provides a logical abstraction of time for reactive system design which allows automatic synthesis of embedded programs that behave in a predictable, timely and reactive manner. According to the synchrony hypothesis, a synchronous model reacts to input events and generates outputs that are immediately made available. But even though synchrony greatly simplifies design of complex systems, it often leads to rejecting models when data dependencies within a reaction are ill-specified, leading to causal cycles. Constructivity is a key property to guarantee that the output during each reaction can be algorithmically determined. Polychrony deviates from perfect synchrony by using a partially ordered or relational model of time. It captures the behaviors of (implicitly) multi-clocked data-flow networks and can analyze and synthesize them to GALS systems or to Kahn process networks (KPNs). In this paper, we provide a unified constructive semantic framework, using structural operational semantics, which captures the behavior of both synchronous modules and multi-clocked polychronous processes. Along the way, we define the very first operational semantics of Signal.

show abstract

A Synchronous Language at Work: The Story of Lustre

Cited by 25 publications

References 25 publications

Clock refinement in imperative synchronous languages

Clock refinement in imperative synchronous languages

Modular Verification of Synchronous Programs

Constructive polychronous systems

Contact Info

Product

Resources

About