Real-Time Workshop

Advanced Options Pane

The Advanced pane includes several options that affect the performance of generated code. The Advanced pane has two sections. Options in the Model parameter configuration section let you specify how block parameters are represented in generated code, and how they are interfaced to externally written code. Options in the Optimizations section help you to optimize both memory usage and code size and efficiency.

Note that the Zero crossing detection option affects only simulations with variable-step solvers. Therefore, this option is only applicable to code generation when using the rapid simulation (rsim) target, which is the only target that allows variable-step solvers. See the Simulink documentation for further information on the Zero crossing detection option.

Inline Parameters Option

Selecting this option has two effects:

1. Real-Time Workshop uses the numerical values of model parameters, instead of their symbolic names, in generated code.

1. If the value of a parameter is a workspace variable, or an expression including one or more workspace variables, the variable or expression is evaluated at code generation time. The hard-coded result value appears in the generated code. An inlined parameter, since it has in effect been transformed into a constant, is no longer tunable. That is, it is not visible to externally written code, and its value cannot be changed at run-time.

2. The Configure button becomes enabled. Clicking the Configure button opens the Model Parameter Configuration dialog box.

1. The Model Parameter Configuration dialog box lets you remove individual parameters from inlining and declare them to be tunable variables (or global constants). When you declare a parameter tunable, Real-Time Workshop generates a storage declaration that allows the parameter to be interfaced to externally written code. This enables your hand-written code to change the value of the parameter at run-time.

   The Model Parameter Configuration dialog box lets you improve overall efficiency by inlining most parameters, while at the same time retaining the flexibility of run-time tuning for selected parameters.

   See Parameters: Storage, Interfacing, and Tuning for further information on interfacing parameters to externally written code.

The Inline parameters option also instructs Simulink to propagate constant sample times. Simulink computes the output signals of blocks that have constant sample times once during model startup. This improves performance, since such blocks do not compute their outputs at every time step of the model.

Selecting Inline parameters also interacts with other code generation parameters as follows:

• When Inline parameters is selected, the Inline invariant signals code generation option becomes available. See Inline Invariant Signals Option.
• The Parameter pooling option is used only when Inline parameters is selected. See Parameter Pooling Option.

Block Reduction Option

When this option is selected, Simulink collapses certain groups of blocks into a single, more efficient block, or removes them entirely. This results in faster model execution during simulation and in generated code. The appearance of the source model does not change.

By default, the Block reduction option is on.

The types of block reduction optimizations currently supported are

Accumulator Folding. .   Simulink recognizes certain constructs as accumulators, and reduces them to a single block. For a detailed example, see Accumulators.

Removal of Redundant Type Conversions.   Unnecessary type conversion blocks are removed. For example, an int type conversion block whose input and output are of type int is redundant and will be removed.

Dead Code Elimination.   Any blocks or signals in an unused code path are eliminated from the generated code the Block reduction option is on. There are three conditions that all need to be met for a block to be considered part of an unused code path:

1. The block is in a signal path that ends with a Terminator block or a disabled Assertion block.
2. The block is not in any other signal path.
3. The block does not reference any tunable or global parameters or signal storage.

Consider the model in the following block diagram.

Code is always generated for the signal path between In1 and Out1, because this path does not meet condition 1 above. If Inline parameters is off, code is also generated for the signal path between the In2 and Terminator blocks, because condition 3 is not satisfied (Gain2 is tunable).

If Inline parameters is on, however, the terminated signal path meets all three conditions, and is eliminated. The resultant MdlOutputs function is shown in the following code excerpt.

• void MdlOutputs(int_T tid)
  {
  
    /* Outport: '/Out1' incorporates:
     *   Gain: '/Gain1'
     *   Inport: '/In1'
     *
     * Regarding '/Gain1':
     *   Gain value: 2.0
     */
    rtY.Out1 = (2.0 * rtU.In1);
  }
  

Boolean Logic Signals Option

By default, Simulink does not signal an error when it detects that double signals are connected to blocks that prefer Boolean input. This ensures compatibility with models created by earlier versions of Simulink that support only double data types. You can enable strict Boolean type checking by selecting the Boolean logic signals option.

Selecting this option is recommended. Generated code will require less memory, because a Boolean signal typically requires one byte of storage while a double signal requires eight bytes of storage.

Parameter Pooling Option

Parameter pooling occurs when multiple block parameters refer to storage locations that are separately defined but structurally identical. The optimization is similar to that of a C compiler that encounters declarations such as:

• int a[] = {1,2,3}; 
  int b[] = {1,2,3}; 
  

In such a case, an optimizing compiler would collapse a and b into a single text location containing the values 1, 2, 3 and initialize a and b from the same code.

To understand the effect of parameter pooling in Real-Time Workshop, consider the following scenario.

Assume that the MATLAB workspace variables a and b are defined as follows:

• a = [1:1000]; b = [1:1000];
  

Suppose that a and b are used as vectors of input and output values in two Look-Up Table blocks in a model. Figure 2-6 shows the model.

Figure 2-6: Model with Pooled Storage for Look-Up Table Blocks

The figure below shows the use of a and b as a parameters of the Look-Up Table1 and Look-Up Table2 blocks.

Figure 2-7: Pooled Storage in Look-Up Table Blocks

If Parameter pooling is on, pooled storage is used for the input/output data of the Look-Up Table blocks. The following code fragment shows the definition of the global parameter structure of the model (rtP). The input data references to a and b are pooled in the field rtP.p2. Likewise, while the output data references (expressions including a and b) are pooled in the field rtP.p3.

• typedef struct Parameters_tag {
  real_T p2[1000]; /* Variable: p2
                    * External Mode Tunable: no
                    * Referenced by blocks:
                    * <Root>/Look-Up Table1
                    * <Root>/Look-Up Table2
                    */
  real_T p3[1000]; /* Expression: tanh(a)
                    * External Mode Tunable: no
                    * Referenced by blocks:
                    * <Root>/Look-Up Table1
                    * <Root>/Look-Up Table2
                    */
  } Parameters;
  

If Parameter pooling is off, separate arrays are declared for the input/output data of the Look-Up Table blocks. Twice the amount of storage is used:

• typedef struct Parameters_tag {
    real_T root_Look_Up_Table1_XData[1000]; 
    real_T root_Look_Up_Table1_YData[1000];
    real_T root_Look_Up_Table2_XData[1000];
    real_T root_Look_Up_Table2_YData[1000];
  } Parameters;
  

The Parameter pooling option has the following advantages:

• Reduces ROM size
• Reduces RAM size for all compilers (rtP is a global vector)
• Speeds up code generation by reducing the size of model.rtw
• Can speed up execution

Note that the generated parameter names consist of the letter p followed by a number generated by Real-Time Workshop. Comments indicate what parameters are pooled.

Note    The Parameter pooling option affects code generation only when Inline parameters is on.

Signal Storage Reuse Option

This option instructs Real-Time Workshop to reuse signal memory. This reduces the memory requirements of your real-time program. We recommend selecting this option. Disabling Signal storage reuse makes all block outputs global and unique, which in many cases significantly increases RAM and ROM usage.

For further details on the Signal storage reuse option, see Signals: Storage, Optimization, and Interfacing.

Note    Selecting Signal storage reuse also enables the Local block outputs option and the Buffer reuse option in the General code generation options category of the Real-Time Workshop pane. See Local Block Outputs Option and Buffer Reuse Option.

Control over Assertion Block Behavior

The Advanced pane of the Simulation Parameters dialog shown above also provides you with a contol to specify whether model verification blocks such as Assert, Check Static Gap, and related range check blocks will be enabled, not enabled, or default to their local settings. This Model Verification block control popup menu has the same effect on code generated by Real-Time Workshop as it does on simulation behavior.

For Assertion blocks that are not disabled, the generated code for a model will include one of the following statements

• utAssert(input_signal);
  utAssert(input_signal != 0.0);
  utAssert(input_signal != 0);
  

at appropriate locations, depending on the block's input signal type (Boolean, real, or integer, respectively).

By default utAssert is a noop in generated code. For assertions to abort execution you must enable them by including a parameter in the make_rtw command. Specify the Make command field on the Target configuration category pane as follows:

• make_rtw OPTS='-DDOASSERTS'
  

If you want triggered assertions to not abort execution and instead to print out the assertion statement, use the following make_rtw variant:

• make_rtw OPTS='-DDOASSERTS -DPRINT_ASSERTS'
  

utAssert is defined as

• #define utAssert(exp)  assert(exp)
  

You can provide your own definition of utAssert in a hand-coded header file if you wish to customize assertion behavior in generated code. See <matlabroot>/rtw/c/libsrc/rtlibsrc.h for implementation details.

Finally, when running a model in accelerator mode, Simulink will call back to itself to execute assertion blocks instead of using generated code. Thus user-defined callback will still be called when assertions fail.

Diagnostics Pane Options

Tracing Generated Code Back to Your Simulink Model