Rate Transitions and Asynchronous Blocks

Because an asynchronous function call subsystem can preempt or be preempted by other model code, an inconsistency arises when more than one signal element is connected to an asynchronous block. The issue is that signals passed to and from the function call subsystem can be in the process of being written to or read from when the preemption occurs. Thus, some old and some new data is used. This situation can also occur with scalar signals in some cases. For example, if a signal is a double (8 bytes), the read or write operation might require two machine instructions.

Note

The operating system integration techniques that are demonstrated in this topic use blocks that are in the Interrupt Templates block library. The blocks in that library serve as examples to help you develop custom blocks for a specific target environment.

About Rate Transitions and Asynchronous Blocks

The Simulink^® Rate Transition block is designed to deal with preemption problems that occur in data transfer between blocks running at different rates. These issues are discussed in Time-Based Scheduling and Code Generation.

You can handle rate transition issues automatically by selecting model configuratoin parameter Automatically handle rate transition for data transfer. This saves you from having to manually insert Rate Transition blocks to avoid invalid rate transitions, including invalid asynchronous-to-periodic and asynchronous-to-asynchronous rate transitions, in multirate models. For asynchronous tasks, the Simulink engine configures inserted blocks for data integrity but not determinism during data transfers.

For asynchronous rate transitions, the Rate Transition block provides data integrity, but cannot provide determinism. Therefore, when you insert Rate Transition blocks explicitly, you must clear the block parameter Ensure deterministic data transfer (maximum delay).

When you insert a Rate Transition block between two blocks to maintain data integrity and priorities are assigned to the tasks associated with the blocks, the code generator assumes that the higher priority task can preempt the lower priority task and the lower priority task cannot preempt the higher priority task. If the priority associated with task for either block is not assigned or the priorities of the tasks for both blocks are the same, the code generator assumes that either task can preempt the other task.

Priorities of periodic tasks are assigned by the Simulink engine, in accordance with the parameters specified in the Solver selection section of the Solver pane of the Configuration Parameters dialog box. When the Periodic sample time constraint parameter is set to Unconstrained, the model base rate priority is set to 40. Priorities for subrates then increment or decrement by 1 from the base rate priority, depending on the setting of parameter Higher priority value indicates higher task priority.

You can assign priorities manually by using parameter Periodic sample time properties. The Simulink engine does not assign a priority to asynchronous blocks. For example, the priority of a function call subsystem that connects back to an Async Interrupt block is assigned by the Async Interrupt block.

Block parameter Simulink task priority of the Async Interrupt block specifies a priority level (required) for every interrupt number entered for parameter VME interrupt number(s). The priority array sets the priorities of the subsystems connected to each interrupt.

For the Task Sync block, if the example RTOS (VxWorks^®) is the target, clear block parameter Higher priority value indicates higher task priority. Parameter Simulink task priority specifies the block priority relative to connected blocks (in addition to assigning an RTOS priority to the generated task code).

The vxlib1 library provides two types of rate transition blocks as a convenience. These are simply preconfigured instances of the Rate Transition block:

Protected Rate Transition block: Rate Transition block that is configured with block parameter Ensure data integrity during data transfers selected and Ensure deterministic data transfer cleared.
Unprotected Rate Transition block: Rate Transition block that is configured with the Ensure data integrity during data transfers cleared.

Handle Rate Transitions for Asynchronous Tasks

For rate transitions that involve asynchronous tasks, you can maintain data integrity. However, you cannot achieve determinism. You have the option of using the Rate Transition block or target-specific rate transition blocks.

Consider the following model, which includes a Rate Transition block.

Model that includes a Rate Transition block

You can use the Rate Transition block in either of the following modes:

Maintain data integrity, no determinism
Unprotected

Alternatively, you can use target-specific rate transition blocks. The following blocks are available for the example RTOS (VxWorks):

Protected Rate Transition block (reader)
Protected Rate Transition block (writer)
Unprotected Rate Transition block

Handle Multiple Asynchronous Interrupts

Consider the following model, in which two functions trigger the same subsystem.

Model that includes two functions that trigger the same subsystem

The two tasks must have equal priorities. When priorities are the same, the outcome depends on whether they are firing periodically or asynchronously, and also on a diagnostic setting. The following table and notes describe these outcomes:

Supported Sample Time and Priority for Function Call Subsystem with Multiple Triggers

	Async Priority = 1	Async Priority = 2	Async Priority Unspecified	Periodic Priority = 1	Periodic Priority = 2
Async Priority = 1	Supported (1)
Async Priority = 2		Supported (1)
Async Priority Unspecified			Supported (2)
Periodic Priority = 1				Supported
Periodic Priority = 2					Supported

Control these outcomes by using model configuratoin parameter Tasks with equal priority ; set this diagnostic to none if tasks of equal priority cannot preempt each other in the target system.

For this case, the following warning message is issued unconditionally:

The function call subsystem <name> has multiple asynchronous 
triggers that do not specify priority. Data integrity will 
not be maintained if these triggers can preempt one another.

Empty cells in the above table represent multiple triggers with differing priorities, which are unsupported.

The code generator provides absolute time management for a function call subsystem connected to multiple interrupts in the case where timer settings for TriggerA and TriggerB (time source, resolution) are the same.

Assume that all of the following conditions are true for the model shown above:

A function call subsystem is triggered by two asynchronous triggers (TriggerA and TriggerB) having identical priority settings.
Each trigger sets the source of time and timer attributes by calling the functions ssSetTimeSource and ssSetAsyncTimerAttributes.
The triggered subsystem contains a block that needs elapsed or absolute time (for example, a Discrete Time Integrator).

The asynchronous function call subsystem has one global variable, clockTick# (where # is the task ID associated with the subsystem). This variable stores absolute time for the asynchronous task. There are two ways timing can be handled:

If the time source is set to SS_TIMESOURCE_BASERATE, the code generator produces timer code in the function call subsystem, updating the clock tick variable from the base rate clock tick. Data integrity is maintained if the same priority is assigned to TriggerA and TriggerB.
If the time source is SS_TIMESOURCE_SELF, generated code for both TriggerA and TriggerB updates the same clock tick variable from the hardware clock.

The word size of the clock tick variable can be set directly or be established according to setting of model configuration parameter Application lifespan (days) and the timer resolution set by the TriggerA and TriggerB S-functions (which must be the same). See Timers in Asynchronous Tasks and Optimize Memory Usage and Prevent Overflows for Time Counters for more information.

Protect Data Integrity with `volatile` Keyword

When you select block parameter Ensure data integrity during data transfer, the code generated for a Rate Transition block defines volatile global buffers and semaphores and uses them to protect the integrity of the transferred data. For additional protection, or for protection without a Rate Transition block, you can explicitly apply volatile to the transferred data. For more information, see Protect Global Data with const and volatile Type Qualifiers (Embedded Coder).