Run-time Environment

To ensure an equivalent execution behavior between a generator input model and its corresponding ANSI C code implementation, the generator output includes an additional run-time environment.

The principle task of this run-time environment is to control execution of interconnected FSM instances. Since FSM modules are designed and simulated under a discret event (DE) model of computation, the run-time environment must ensure an equivalent run-time behavior for every FSM instance. Based on the fact that generated output code is mainly used as software control units in an embedded and real-time application field, additional real-time conditions have to be considered in conjunction with event dispatching time and FSM instance execution duration. In this context, the run-time environment can be considered as a real-time operating system (RTOS) and every state machine instance represents a system task.

Scheduler

The underlying RTOS scheduler is basically an ANSI C reimplementation of the integrated MLDesigner DE priority-free scheduler.

Event Queue

Central scheduler element is an event queue (EventQ), represented by a single linked list of EventQ entries. An EventQ entry combines all information, required to perform a specific task.

Task Interaction

Connections between FSM instances are implemented via emitter and deliver functions. The RTOS includes an emitter function for each individual instance output port and a deliver function for each non-terminated instance input port, respectively.

During instance execution, an emitter function is called whenever the appropriate output port is triggered to send new events. Internally, this function schedules a new EventQ entry for each connected instance input port.

Whenever the scheduler processes an input EventQ entry, the deliver function of the appropriate instance input port is called.

Interface Interaction

Similar to interaction between FSM instances, the RTOS manages FSM module interface ports on the basis of customizable generic get and send functions (see Interface Configuration).

The get function of each individual interface input port returns a boolean value (either 1 for true or 0 for false) to determine presence of a new event on this input port. Directly after a clock tick has been occured, the scheduler calls all present get functions to check the module interface for new input events. In case a new event is present on an interface input port, an EventQ entry is scheduled for each connected instance input port.

If an instance output port is connected to an interface output port, the associated send function is called inside the instance output emitter function to send new data to the module output interface. In the special case that an interface input port is directly connected to an interface output port, no EventQ entry is scheduled and the output send function is called directly after the scheduler grabbed a new event by the input get function.

Timelines

In reference to an underlying DE model of computation and additional real-time conditions, the RTOS includes two separate timelines.

First, an external clock tick timeline of a configured clock tick interval (CTI) determines the global system clock pulse. A corresponding clock tick counter (CTC) is incremented each time a clock tick occurred.

Secondly, an internal system time counter (STC) is used as time base for EventQ entries. To ensure a quasi-zero-delayed execution behavior of FSM instances, the STC is not updated until all scheduled synchronous events for this timestamp are processed.

While the scheduler is able to perform all tasks, related to a specific system timestamp, within one clock tick period, both timelines are running synchronously. Otherwise, in case processing of all events, scheduled for the current internal system time, exceeds the CTI limit, a clock tick overrun occurs and given real-time conditions might be violated. In a soft real-time system, a clock tick overrun might be ignorable, but in case of hard real-time conditions, the application usually has to be aborted and reconfigured with a longer clock tick interval. To define consequences of a real-time violation, the generator output provides a configurable handler function, which is called whenever the defined real-time level could not be met.

The figure below shows an example soft real-time scenario with the time response of both RTOS timelines. All RTOS timeline related configuration units are described in detail in the Porting section.

Custom Memory Management

The RTOS includes a separate dynamic memory management, customized for a particular generator input model.

Within implementation of FSM modules, dynamic memory management is only essential in conjunction with EventQ entries and associated input event data, since the number of scheduled events is permanently changing. In this context, the RTOS memory handling is based on partitions of contiguous memory areas. Thereby, a particular FSM module requires as many partitions as different data types are used between input/output port connections. Additionally, one special partition is necessary in conjunction with EventQ entries.

Each partition is subdivided into a configurable number of fixed-sized memory blocks. In doing so, the block byte size is typically equivalent to the appropriate data type size. Within a particular partition, all free blocks are handled by a single linked list. In other words, if a specific data type representation requires n bytes, the related memory partition is subdivided into blocks of size n.

But since all free blocks of a partition are connected on the basis of pointer links, at least as many bytes are used for a block as are needed by the run-time system to implement a pointer. This means that if, for instance, a data type requires two bytes, but a specific run-time system uses 4 bytes to implement a pointer, the appropriate memory partition is subdivided into blocks of 4 bytes.

The total number of reserved partition blocks is configurable. But to ensure robust output code, all partitions are initially divided into as many blocks as are determined on the basis of a worst case execution scenario. This means that, for instance, the code generator counts the number of input/output connections inside a given input FSM module and reserves that much blocks for EventQ entries for the case that all input events are simultaneously scheduled. If this case can be excluded, the total number of EventQ entry blocks can be reduced to save system memory.