Rate Transitions

What Is a Rate Transition?

Rate transitions exist in multirate models between blocks that exchange data over a signal line and are configured to use different sample times. A rate transition is represented in a model as a Rate Transition block that the Simulink^® engine inserts for you or you insert manually on the signal line that connects the blocks that exchange data.

For information about tradeoffs that you can make regarding rate transitions, see Control Data Transfer Behavior in Generated Code.

Types of Rate Transitions

This table lists the types of rate transitions that can exist in multirate models.

Type	Description
Periodic fast-to-slow	A block configured to use a faster periodic sample time drives a block that is configured to use a slower periodic sample time.
Periodic slow-to-fast	A block configured to use a slower periodic sample time drives a block that is configured to use a faster periodic sample time.
Asynchronous-to-periodic	A block configured to use an asynchronous sample time drives a block that is configured to use a periodic sample time.
Asynchronous-to-asynchronous	A block configured to use an asynchronous sample time drives another block that is configured to use an asynchronous sample time.

In multirate systems, differing sample rates can cause blocks to run in the wrong order. To prevent possible errors in calculated data, you must control model execution at these transitions. When connected blocks have different sample rates, you or the Simulink engine must add a Rate Transition block between them.

Periodic Fast-to-Slow Rate Transitions

This figure shows a model configured to use sample times with a zero offset and a periodic fast-to-slow rate transition. The faster block that is configured to use a sample rate of 1 second drives a slower block that is configured to use a sample rate of 2 seconds. The Rate Transition block handles the transfer of data between the output port of the block operating at 1 second and the input port of the block operating at 2 seconds.

Periodic Fast-to-Slow Rate Transitions During Simulation

During simulation, when a model includes a faster block that drives a slower block and the slower block has direct feedthrough, the output of the faster block is computed first. During simulation intervals when the slower block does not run, the simulation progresses more rapidly because there are fewer blocks to run.

This figure shows the situation described above. The timing diagram assumes that the Rate Transition block is used with its default settings, with Ensure data integrity during data transfer and Ensure deterministic data transfer selected.

In the diagram, the vertical dotted lines that are labeled t0 to t3 indicate the start of a simulation interval. The lighter blue boxes represent Simulink engine execution of the tasks for the faster block and the darker blue boxes represent execution of the tasks for the slower blocks.

The simulation does not run in real time, which means that it is not bound by real-time constraints. The simulation waits for or moves ahead to with tasks required to complete the simulation flow without introducing processor idle time. For example, the diagram shows the slower task starts executing when execution of the faster task completes regardless of when the next time step occurs.

Fast-to-Slow Periodic Rate Transitions During Generated Code Execution

During execution of code generated from a model where a faster block drives a slower block, you must compensate for the execution of the task for the slower block possibly spanning multiple execution periods of the task for the faster block. As a result, the output of the task for the faster block can change before the task for the slower block finishes computing its output.

This figure shows the situation described above. In this case, the faster block runs as a higher-priority task. The higher priority task preempts the lower priority task before the lower priority task finishes executing.

In the figure, the vertical dotted lines that are labeled t0 to t3 indicate the start of a task step. The lighter blue boxes represent Simulink engine execution of the tasks for the faster block and the darker blue boxes represent execution of the tasks for the slower blocks. The curved arrows represent data being passed between tasks.

In the preceding diagram:

The task for the faster block (T=1s) completes execution and sends its output to the task for the slower block (T=2s).
The higher priority task (T=1s) preempts the lower priority task (T=2s) and starts executing, using the output of the lower-priority task.
The task for the faster block completes execution and sends its output to the task for the slower block, which resumes execution using modified data.

The task for the faster block runs a second time before the task for the slower block finishes executing. Data integrity can be compromised because the input data to the slower task changes, which can cause unpredictable results.

To maintain data integrity, the Simulink engine must hold the output of the task for the faster block in a buffer until the task for the slower block finishes executing. To accomplish this, insert a Rate Transition block between the faster and slower blocks. The Rate Transition block enables the task for the slower block to preserve its input during execution, maintaining data integrity.

For this timing diagram, the code for the Rate Transition block runs at the sample rate of the task for the slower block, but with the priority of the task for the faster block.

In this diagram:

The task for the faster block runs, producing output that is stored by the Rate Transition block.
The Rate Transition block runs before the task for the slower block because its priority is higher. The Rate Transition block code holds the output of the faster block constant while the task for the slower block runs, maintaining data integrity.

Periodic Slow-to-Fast Rate Transitions

This figure shows a model configured to use sample times with a zero offset and a periodic slow-to-fast rate transition. The slower block that is configured to use a sample rate of 2 seconds drives a faster block that is configured to use a sample rate of 1 second. The inserted Rate Transition block handles the transfer of data between the output port of the block operating at 2 seconds and the input port of the block operating at 1 second.

Periodic Slow-to-Fast Periodic Rate Transitions During Simulation

During simulation of a model that includes a slower block that drives a faster block, the Simulink engine computes the output of the driving block first. During sample intervals where only the task for the faster block runs, the simulation progresses more rapidly.

This figure shows the execution sequence. The timing diagram assumes that the Rate Transition block is used with its default settings, with Ensure data integrity during data transfer and Ensure deterministic data transfer selected.

The simulation does not run in real time, which means that it is not bound by real-time constraints. The simulation waits for, or moves ahead to, whatever tasks are required to complete simulation flow without introducing processor idle time. The preceding diagram shows how during sample intervals where only the task for the faster block runs (for example, from t1 to t2), the simulation progresses more rapidly.

Slow-to-Fast Periodic Rate Transitions During Generated Code Execution

In models that include a slower block that drives a faster block, by default, the code generator assigns the task for the faster block a higher priority than the task for the slower block. This means the task for the faster block runs before the task for the slower block. To avoid incorrect results, this situation requires special care.

This timing diagram shows how a higher-priority task for a faster block can interrupt the task for a slower block, read data from the task for the slower block possibly prematurely, and complete execution. Because the task for the slower block did not run to completion before sending the data, data integrity can be compromised.

In the figure, the vertical dotted lines that are labeled t0 to t3 indicate the start of a task step. The lighter blue boxes represent Simulink engine execution of the tasks for the faster block and the darker blue boxes represent execution of the tasks for the slower blocks The curved arrows represent data being passed between tasks.

In this diagram:

The task for the faster block (T=1s) starts and completes execution.
The task for the slower block (T=2s) starts executing.
Before the task for the slower block finishes execution, the higher priority task (T=1s) preempts that task and starts executing, using output of the lower-priority task.
The task for the faster block completes execution, potentially using incorrect data.
The task for the slower block completes execution.
At the start of the next sample interval, the task for the faster block runs, using output read from the task for the slower block at the time that task completes execution.

The timing diagram shows two problems:

The task for the faster block runs before the task for the slower block, but the input to the task for the faster block has not been computed. This can cause unpredictable results.
Execution of the task for the slower block is split across multiple faster block intervals. The task for the faster block runs a second time before the task for the slower block finishes executing, which can result in the inputs to the task for the faster block providing incorrect values when it interrupts the slower task.

To eliminate these problems, insert a Rate Transition block between the slower and faster blocks.

This figure shows the timing sequence that results with an added Rate Transition block with its default settings, with Ensure data integrity during data transfer and Ensure deterministic data transfer selected.

In this diagram:

The Rate Transition block output runs at the rate of the task for the slower block but in the context of the higher priority task, which is the higher priority task.
The task for the faster block runs, using the output of the Rate Transition block, which is a specified initial value.
When the task for the faster block finishes execution, the task for the slower task starts executing, using the output of the task for the faster block.
Before the task for the slower block finishes execution, the higher priority task (T=1s) preempts that task and starts executing, using output of the Rate Transition block (the same output that was used by the task for the slower block).
The task for the faster block completes execution.
The task for the slower block completes execution.
The state of the Rate Transition block is updated, using the output of the task for the slower block.
The Rate Transition block output in the task for the faster block uses the state of the Rate Transition block that was updated in the task for the slower block.
At the start of the next sample interval, the task for the faster block runs, using the updated value of the Rate Transition block.

The Rate Transition block addresses the two issues cited earlier:

Without the Rate Transition block, the task for the faster block runs before the task for the slower block, but the input to the task for the faster block has not been computed. Insertion of the Rate Transition block addresses this because the task for that block runs at a slower rate and its output does not change during the computation of the task for the faster block that it is driving. The output of the Rate Transition block runs at the sample rate of the task for the slower block, but with the priority of the task for the faster block. Since the Rate Transition block drives the task for the faster block and has the same priority, that code runs before the task for the faster block and acquires an initial value.
Because execution of the task for the slower block is split across multiple faster block intervals, the task for the faster block runs a second time before the task for the slower block finishes executing. This situation can result in the inputs to the task for the faster block providing incorrect values. Insertion of the Rate Transition block fixes this because the Rate Transition block updates at a slower rate and at the priority of the task for the slower block. The input to the Rate Transition block, which is the output of the task for the slower block, is read after the task for the slower block finishes running.

Asynchronous Rate Transitions

Asynchronous function-call subsystems can preempt or be preempted by other model code. In models that include an asynchronous function-call subsystem that drives another function-call subsystem (periodic or asynchronous), priorities of tasks associated with the subsystems determine task preemption rules, which can impact data transfers.

The Simulink engine assigns priorities to periodic tasks based on settings of solver model configuration parameters. When the Periodic sample time constraint parameter is set to Unconstrained, Simulink assigns priority 40 to the sample time that corresponds to the fixed step size for the simulation. The software increments or decrements from 40 by 1 to assign priorities to other tasks depending on the setting of parameter Higher priority value indicates higher task priority.

For asynchronous tasks, the block initiating a trigger event, such as an Async Interrupt block, assigns priorities to connected function-call subsystems. The Async Interrupt block parameter Simulink task priority(s) specifies an array of required priority levels, where each priority-level corresponds to an interrupt number specified for block parameter VME interrupt number(s). The priority array sets the priorities of the subsystems connected to each VME interrupt.

Because an asynchronous function-call subsystem can preempt or be preempted by other model code, an inconsistency arises when multiple signal lines connect to an asynchronous block. A preemption can occur while the function-call subsystem reads and writes the signal data. As a result, some old and some new data is used. This situation can also occur with signal scalar data. For example, if signal data is of type double (8 bytes), the read or write operation might require two machine instructions.

Note

The Async Interrupt block is 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.