Real-Time Workshop

Code Generation Optimizations

The Simulink code generator included with Real-Time Workshop is packed with optimizations to help create fast and minimal size code. The optimizations are classified either as cross-block optimizations, or block specific optimizations. Cross-block optimizations apply to groups of blocks or the general structure of a model. Block specific optimizations are handled locally by the object generating code for a given block. Listing each block specific optimization here is not practical; suffice it to say that the Target Language Compiler technology generates very tight and fast code for each block in your model.

The following sections discuss some of the cross-block optimizations.

Multirate Support

One of the more powerful features of Simulink is its implicit support for multirate systems. The ability to run different parts of a model at different rates guarantees optimal use of the target processor. In addition, Simulink enforces correctness by requiring that you create your model in a manner that guarantees deterministic execution.

Inlining S-Function Blocks for Optimal Code

The ability to add blocks to Simulink via S-functions is enhanced by the Target Language Compiler. You can create blocks that embed the minimal amount of instructions into the generated code. For example, if you create a device driver using an S-function, you can have the generated code produce one line for the device read, as in the following code fragment:

• mdlOutputs(void)
  {
      .
      .
      rtB.deviceout = READHW(); /* Macro to read hw device using 
      .                            assembly code */
      .
  }
  

Note that the generic S-function API is suitable for any basic block-type operation.

Loop Rolling Threshold

The code generated for blocks can contain for loops, or the loop iterations can be "flattened out" into inline statements. For example, the general gain block equation is

• for (i = 0; i < N; i++) {
      y[i] = k[i] * u[i];
  }
  

If N is less than a specified roll threshold, Real-Time Workshop expands out the for loop, otherwise Real-Time Workshop retains the for loop.

Tightly Coupled Optimal Stateflow Interface

The generated code for models that combine Simulink blocks and Stateflow charts is tightly integrated and very efficient.

Stateflow Optimizations

The Stateflow Coder contains a large number of optimizations that produce highly readable and very efficient generated code.

Inlining of Systems

In Simulink, a system starting at a nonvirtual subsystem boundary (e.g. an enabled, triggered, enabled and triggered, function-call, or atomic subsystem) can be inlined by selecting the RTW inline subsystem option from the subsystem block properties dialog. The default action is to inline the subsystem, unless it is a function-call subsystem with multiple callers.

Block I/O Reuse

Consider a model with a D/A converter feeding a gain block (for scaling), then feeding a transfer function block, then feeding a A/D block. If all signals refer to the same memory location, then less memory will be used. This is referred to as block I/O reuse. It is a powerful optimization technique for re-using memory locations. It reduces the number of global variables improving the executing speed (faster execution) and reducing the size of the generated code.

Declaration of Block I/O Variables in Local Scope

If input/output signal variables are not used across function scope, then they can be placed in local scope. This optimization technique reduces code size and improves the execution speed (faster execution).

Inlining of Parameters

If you select the Inline parameters option, the numeric values of block parameters that represent coefficients are embedded in the generated code. If Inline parameters is off, block parameters that represent coefficients can be changed while the model is executing.

Note that it is possible to specify which parameters to tune using the Workspace parameter attributes dialog box.

Inlining of Invariant Signals

An invariant signal is a block output signal that does not change during Simulink simulation. For example, the output of a sum block that is fed by two constants cannot change. When Inline invariant signals is selected on the General code generation options portion of the Real-Time Workshop pane, a single numeric value is placed in the generated code to represent the output value of the sum block. The Inline invariant signals option is available when the Inline parameters option is on.

Parameter Pooling

The Parameter pooling option is available when Inline parameters is selected. If Real-Time Workshop detects identical usage of parameters (e.g. two lookup tables with same tables), it will pool these parameters together, thereby reducing code size.

Block Reduction Optimizations

Real-Time Workshop can detect block patterns (e.g. an accumulator represented by a constant, sum and a delay block) and reduce these patterns to a single operation, resulting in very efficient generated code.

Creation of Contiguous Signals to Speed Block Computations

Some block algorithms (for example a matrix multiply) can be implemented more efficiently if the signals entering the blocks are contiguous. Noncontiguous signals occur because of the handling of virtual blocks. For example, the output of a Mux block is noncontiguous. When this class of block requires a contiguous signal, Simulink will insert (if needed) a copy block operator to make the signal contiguous. This results in better code efficiency.

Support for Noncontiguous Signals by Blocks

Noncontiguous signals occur because of the block virtualization capabilities of Simulink. For example, the output of a Mux block is generally a noncontiguous signal (i.e., the output signal consists of signals from multiple sources). General blocks in Simulink support this behavior by generating very efficient code to handle each different signal source in a noncontiguous signal.

Data Type Support

Simulink models support a wide range of data types. You can use double precision values to represent real-world values and then when needed use integers or Booleans for discrete valued signals. You can also use fixed-point (integer scaling) capabilities to target models for fixed-point embedded processors. The wide selection of data types in Simulink models enables you to realize your models efficiently.

Frame Support

In signal processing, a frame of data represents time sampled sequences of an input. Many devices have support in hardware for collecting frames of data. With Simulink and the DSP Blockset, you can use frames and perform frame based operations on the data. Frames are a very efficient way of handling high frequency signal processing applications.

Matrix Support

Most blocks in Simulink support the use of matrices. This enables you to create models that represent high levels of abstractions and produce very efficient generated code.

Virtualization of Blocks

Nearly half of the blocks in a typical model are connection type blocks (e.g. Virtual Subsystem, Inport, Outport, Goto, From, Selector, Bus Selector, Mux, Demux, Ground, and Terminator). These blocks are provided to enable you to create complex models with your desired levels of abstraction. Simulink treats these blocks as virtual, meaning that they impose no overhead during simulation or in the generated code.

Target Environments

An Open and Extensible Environment