Giotto(ID:7780/)Temporally triggered embedded programming References: External link: Online copy The first stage of the software takes a graphical model as an input to generate intermediate code in the C language. This intermediate code consists of the task-code to be executed, as well as a representation of their timing requirements. The second stage, called the Embedded Machine [5] reads in the timing information and interprets it to release the tasks for execution as per the stated requirements. The released tasks can either be assigned to a standard scheduler such as EDF, or to a scheduling interpreter called the Scheduling machine, or S Machine. The S Machine was developed to gain fine grained control over the scheduling of tasks. The S Machine requires as input scheduling information that specifies a time line for the tasks involved thus giving the designer maximum flexibility over task scheduling, and consequently greater resource utilization. The E&S Machines when compiled along with the generated task and timing code for the KURT-Linux platform forms an executable that delivers predictable real-time performance. The benefit this approach offers is that the real-time tasks can run along with ordinary Linux tasks without the timing properties of the real-time tasks being affected. An audio application was designed to illustrate the effectiveness of this tool-flow, which achieved a timing uncertainty of less than 130 microseconds in its task execution times. External link: Online copy Extract: Giotto Giotto Giotto ?provides an abstract programmer?s model for the implementation of embedded control systems with hard real-time constraints? [2]. The semantics it offers to express system properties are in close alignment with a mathematical model of a control system. This is desirable since control systems are often designed at a mathematical level of abstraction to facilitate effective optimization of control laws, and validate the performance and functionality of the model. The onus of translating a mathematical control model into software falls to the developer who has to create software tasks corresponding to the computations and assign priorities so as to meet the requisite time - 10 - constraints on the specific hardware. This is an ambiguous process with the desired results achieved through the use of an iterative process of testing and debugging. Giotto removes the ambiguity by providing the developer a formal, machinereadable language in which to specify the system requirements that is easily verifiable by the system designer. Giotto follows the time-triggered design paradigm, making it particularly suited for embedded control systems which have hard real time constraints. It requires the specification of the functionality and timing of the computations of a system. The mapping of these properties on to a particular platform is a compilation issue which is kept independent from the specification. This gives Giotto one of its advantages, namely the separation of the design concerns from the platform dependent execution details. This makes it attractive as a language of communication during the initial stages of the design process. Once a software system is specified using Giotto, it remains to map this specification onto a hardware platform. This process can be largely automated through the use of compilers and virtual machines. One such method, which has been used in this project, is the Embedded Machine [5]. The compilation of Giotto guarantees the preservation of the functionality and timing, thereby producing an executable software application that remains faithful to the original mathematical model. Any control application consists of a set of periodic computations, with elements being added and deleted to the set as the system progresses. Giotto has a basic functional unit of a task representing a single periodic computation which is a piece of code written in a programming language like C. Modes represent a fixed set of such tasks. A Giotto program representing a system is a set of modes. It can be in one mode at any point in time, repeatedly invoking the corresponding set of tasks concurrently. A task can be present in multiple modes, with different timing properties in each, and switching between modes is how the addition and deletion of tasks in the system is accomplished in a Giotto program. Tasks communicate data through ports. Every task will have zero or more input ports from which it reads data upon being invoked, and feeds the result of its execution into zero or more output ports. Other than these task ports, a Giotto program also contains sensor ports which read values from sensors, and actuator ports. Sensors and actuators are - 11 - the means by which a Giotto program reads values from the external environment and conveys decisions to it. Every port is persistent in the sense that the port keeps its value over time until updated. Sensor ports are updated by the environment; all other ports are updated by the Giotto program. Task ports communicate data with each other, as well as with sensor and actuator ports, by drivers, which is code that transports and converts values between these ports. While tasks are segments of computation dispatched by a Giotto program to execute on the hardware platform with a finite non-zero amount of time, drivers are considered by Giotto to be instantaneous bits of code. They are called synchronously by a Giotto program in between dispatching tasks. To quote from [2], it is assumed that ?drivers satisfy the synchrony assumption [13], that they can be executed before the environment state changes?. As mentioned above, all the scheduled computations, the synchronous communications between ports, and mode switching occur in real time, a consequence of the time-triggered nature of a Giotto program. ?These time-triggered semantics enable efficient reasoning about the timing behavior of a Giotto program, in particular, whether it conforms to the timing requirements of a mathematical (e.g., Matlab) model of the control design.? [2]. An example time line for an invocation of a task t shown in Figure 1. Figure 1: Time line for the invocation of a Giotto task t (reproduced from [2]) The invocation starts at some time ôstart with a communication phase in which the inputport values are loaded. As per Giotto semantics, the communication phase ?i.e., the - 12 - execution of the input port driver d ? is performed in logically zero time. This synchronous communication phase is followed by a scheduled computation phase where the task t is carried out. At time ôstop the state and output ports of t are updated to the result of the task computation. The length of the interval between ôstart and ôstop is determined by the frequency ùtask. This determines the number of times task t is executed over one Giotto period, specified in the program. Task t is said to be logically running from time ôstart to time ôstop. The Giotto abstraction does not specify when the actual computation of f is performed between ôstart and ôstop. However, the times at which the task output ports are updated are known, and therefore, ?for any given real-time trace of sensor values, all values that are communicated between tasks and to the actuator ports are determined? [2]. Any Giotto realization has to be faithful to this abstraction; for example, task inputs may be loaded after time ôstart, and the execution of f may be preempted by other tasks, as long as at time ôstop the values of the task output ports are those specified by the Giotto semantics. A Giotto program can be realized on a particular program using a compiler and virtual machine such as the Embedded Machine, or E Machine [5]. The Embedded Machine is a virtual machine that aligns the real time interaction between software and physical processes. It separates the running of embedded programs into two phases. The first platform-independent phase interprets and runs E Code (code understood by the E Machine) which is compiled from Giotto programs by the E Machine compiler. E Code supervises the timing ? not the scheduling ? of application tasks. E Code is independent of any particular platform, and is therefore inherently portable. E Code also exhibits predictable timing and output behavior for a particular input behavior, making it a good choice to represent time-triggered Giotto programs. The generated E Code can be checked for schedulability using [6]. However, this requires knowledge specific to the platform such as the Worst Case Execution Times (WCET?s) which can optionally be supplied as annotations in the Giotto code. Once the E Code determines when the tasks have to be released for execution in a Giotto period, they are passed onto the platform dependent phase of the E Machine. - 13 - The platform dependent phase takes care of executing the released tasks on the underlying hardware. The tasks can be scheduled by the E Machine using any standard scheduler such as EDF. However, more fine-grained control is achieved through the use of the S Machine. The S Machine is a platform-dependent scheduling interpreter which interfaces with the E Machine. The tasks released by the E Machine are dispatched by the S Machine according to a schedule specified using a program called S Code. The S Code or Scheduling Code that is interpreted by the S Machine lays out the time line of the tasks to be executed. Due to the flexibility in scheduling policies it offers, it is inherently more expressive than any particular scheduler. It has been shown that using the S Machine results in an improvement in CPU utilization over the EDF scheduler [8]. In addition to providing the designer with flexibility over the task scheduling, the E Code and S Code can together be used to verify the schedulability of a set of tasks on a specific platform [7]. Since it is easier to verify the schedulability than to generate a feasible schedule, the E&S Codes, if distributed along with the tasks, relieve the user from having to come up with a feasible schedule. In essence they carry the proof of schedulability with them. In our design, the E & S Machine shall together be called the ES Machine. A further description of the ES Machine can be found in the Design section. This project uses Giotto as the model for the real-time systems designed using its software. The graphical modeling and simulation properties of the Ptolemy II framework are exploited by using its Giotto domain as the initial design interface. |