STARPro — A new multithreaded direct execution platform for Esterel

Simon Yuan, Sidharta Andalam, Li Hsien Yoong, Partha S. Roop, Zoran Salcic
2009 Electronical Notes in Theoretical Computer Science  
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
more » ... ect 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 UCCFG sd (unrolled concurrent control-flow graph with surface and depth) to represent the structure of an Esterel program in our compiler. UCCFG sd 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. Esterel is a synchronous reactive programming language [3] . Esterel has formal semantics that guarantee reactivity and determinism [2] , resulting in predictable runtime behaviour that greatly simplies the formal verification of programs. These properties are highly desirable in the design and validation of a special class of embedded systems called reactive systems [9] . Reactive systems typically consists of tasks running in parallel. This concurrency is traditionally supported by running an operating system (OS) that manages these tasks. The dynamic nature of an OS makes the programs running in it difficult to debug and verify. The synchronous paradigm that Esterel follows, in contrast, abstracts away the physical time, and synchronizes the program with a global logical clock. All concurrent components of an Esterel program execute in lock-step, evolving in discrete instants of time, known as a tick. Execution is assumed to be infinitely fast between ticks. Hence, the communication between the concurrent components are conceptually instantaneous. Such synchronous execution guarantees that each reaction in Esterel is atomic in every possible sense. This makes race conditions, common in concurrent programming, impossible in Esterel. While such powerful features make it intuitive to write specifications in Esterel, its compilation and efficient execution has been non-trivial. We illustrate some aspects of this complexity using the example shown in Fig. 1(a) . The demoloop example demonstrates three key features of the language: concurrency, synchronous preemption, and instantaneous broadcast communication. It consists of a single module, with its input and output interface signals declared on lines 2 and 3 respectively. The program consists of two parallel threads, beginning from lines 5-11, and lines 13-21 respectively. Both threads are enclosed by their respective non-terminating loops. The ' ' operator is used to denote their synchronous concurrency. The first thread begins by awaiting for input A (line 6). The await statement always pauses for the first instant, and will continue to do so in subsequent instants until its delay predicate (A in this example) becomes true. Once A becomes present, B will be emitted. The emission of B is broadcast to the second thread, which instantaneously reacts to it by emitting C (lines 14-16). The emission of C, in turn, provokes the instantaneous emission of D back in the first thread (lines 8-10). Meanwhile, in the second thread, the pause statement on line 17 marks the end of its tick, and implies synchronization with the first thread before the start of the next instant. The possibility of instantaneous dialog, as well as this implicit synchronization at each instant between concurrent components, are two factors that make the efficient software implementation of Esterel challenging. In the subsequent instant, the first thread will again wait for another occurrence of A. If A is not present this time, the latter thread will respond by emitting E (lines 18-20) . The ability to react instantaneously to both signal
doi:10.1016/j.entcs.2008.01.005 fatcat:nv34m2aabzba3eer3fm5xamywu