Real-Time Workshop User's Guide    

Other Interactions Between Simulink
and the Real-Time Workshop

The Simulink engine propagates data from one block to the next along signal lines. The data propagated are:

The first stage of code generation is compilation of the block diagram. This compile stage is analogous to that of a C program. The C compiler carries out type checking and pre-processing. Similarly, Simulink verifies that input/output data types of block ports are consistent, line widths between blocks are of the correct thickness, and the sample times of connecting blocks are consistent.

The Simulink engine typically derives signal attributes from a source block. For example, the Inport block's parameters dialog box specifies the signal attributes for the block.

In this example, the Inport block has a port width of 3, a sample time of .01 seconds, the data type is double, and the signal is complex.

This figure shows the propagation of the signal attributes associated with the Inport block through a simple block diagram.

In this example, the Gain and Outport blocks inherit the attributes specified for the Inport block.

Sample Time Propagation

Inherited sample times in source blocks (e.g., a root inport) can sometimes lead to unexpected and unintended sample time assignments. Since a block may specify an inherited sample time, information available at the outset is often insufficient to compile a block diagram completely. In such cases, the Simulink engine propagates the known or assigned sample times to those blocks that have inherited sample times but which have not yet been assigned a sample time. Thus, Simulink continues to fill in the blanks (the unknown sample times) until sample times have been assigned to as many blocks as possible. Blocks that still do not have a sample time are assigned a default sample time according to the following rules:

  1. If the current system has at least one rate in it, the block is assigned the fastest rate.
  2. If no rate exists and the model is configured for a variable-step solver, the block is assigned a continuous sample time (but fixed in minor time steps). Note that the Real-Time Workshop (with the exception of the S-Function Target) does not currently support variable-step solvers.
  3. If no rate exists and the model is configured for a fixed-step solver, the block is assigned a discrete sample time of (Tf - Ti)/50, where Ti is the simulation start time and Tf is the simulation stop time. If Tf is infinity, the default sample time is set to 0.2.

To ensure a completely deterministic model (one where no sample times are set using the above rules), you should explicitly specify the sample time of all your source blocks. Source blocks include root inport blocks and any blocks without input ports. You do not have to set subsystem input port sample times. You may want to do so, however, when creating modular systems.

An unconnected input implicitly sources ground. For ground blocks and ground connections, the default sample time is derived from destination blocks or the default rule.

Block Execution Order

Once Simulink compiles the block diagram, it creates a model.rtw file (analogous to an object file generated from a C file). The model.rtw file contains all the connection information of the model, as well as the necessary signal attributes. Thus, the timing engine in the Real-Time Workshop knows when blocks with different rates should be executed.

You cannot override this execution order by directly calling a block (in hand-written code) in a model. For example, the disconnected_trigger model below will have its trigger port source to ground, which may lead to all blocks inheriting a constant sample time. Calling the trigger function, f(), directly from hand-code will not work correctly and should never be done. Instead, you should use a function-call generator to properly specify the rate at which f() should be executed, as shown in the connected_trigger model below.

Instead of the function-call generator, you could use any other block that can drive the trigger port. Then, you should call the model's main entry point to execute the trigger function.

For multirate models, a common use of the Real-Time Workshop is to build individual models separately and then hand-code the I/O between the models. This approach places the burden of data consistency between models on the developer of the models. Another approach is to let Simulink and the Real-Time Workshop ensure data consistency between rates and generate multirate code for use in a multitasking environment. The Real-Time Workshop Interrupt Template and VxWorks Support libraries provide blocks which allow synchronous and asynchronous data flow. For a description of the Real-Time Workshop libraries, see Chapter 14, Custom Code Blocks and Chapter 15, Asynchronous Support. For more information on multi-rate code generation, see Chapter 7, Models with Multiple Sample Rates.


 Tracing Generated Code Back to Your Simulink Model Selecting a Target Configuration