Real-Time Workshop User's Guide    

Slower to Faster Transitions in Real Time

In models where a slower block drives a faster block, the generated code assigns the faster block a higher priority than the slower block. This means the faster block is executed before the slower block, which requires special care to avoid incorrect results.

Figure 7-9: Time Overlaps in Slower to Faster Transitions

This timing diagram illustrates two problems:

  1. Execution of the slower block is split over more than one faster block interval. In this case the faster task executes a second time before the slower task has completed execution. This means the inputs to the slower task can change, causing unpredictable results.
  2. The faster block executes before the slower block (which is backwards from the way Simulink operates). In this case, the 1 second block executes first; but the inputs to the faster task have not been computed. This can cause unpredictable results.

To eliminate these problems, you must insert a Unit Delay block between the slower and faster blocks. The sample rate for a Unit Delay block must be set to that of the block that is driving it (i.e., the slower block).

The picture below shows the timing sequence that results with the added Unit Delay block.

Three key points about this diagram:

  1. Unit delay output runs in 1 second task, but only at its rate (2 seconds). The output of the unit delay block feeds the 1 second task blocks.
  2. The unit delay update uses the output of the 2 second task in its update of its internal state.
  3. The unit delay update uses the state of the unit delay in the 1 second task.

The output portion of a Unit Delay block is executed at the sample rate of the slower block, but with the priority of the faster block. Since a Unit Delay block drives the faster block and has effectively the same priority, it is executed before the faster block. This solves the first problem.

The second problem is alleviated because the Unit Delay block executes at a slower rate and its output does not change during the computation of the faster block it is driving.


 Slower to Faster Transitions in Simulink Optimizing the Model for Code Generation