Real-Time Workshop User's Guide

Advanced Options Page

The Advanced page includes several options that affect the performance of generated code. The Advanced page 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 not applicable to code generation. See Using Simulink for further information on the Zero crossing detection option.

Inline Parameters Option

Selecting this option has two effects:

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

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.

The Model Parameter Configuration dialog lets you remove individual parameters from inlining and declare them to be tunable variables (or global constants). When you declare a parameter tunable, the 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 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.

Inline parameters 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.
• You cannot inline parameters when using external mode. External mode requires that all parameters be tunable. See Chapter 5, External Mode.
• 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. 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.
• 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.

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 type. 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 the 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 3-4 shows the model.

Figure 3-4: Model with Pooled Storage for Look-Up Table Blocks

Figure 3-5 shows the use of a and b as a parameters of Look-Up Table1and Look-Up Table2.

Figure 3-5: 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 the 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 the Real-Time Workshop to reuse signal memory. This reduces the memory requirements of your real-time program. Selecting this option is recommended. 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 in the General code generation options category of the Real-Time Workshop page. See Local Block Outputs Option.

Diagnostics Page Options

Tracing Generated Code Back to Your Simulink Model