Real-Time Workshop Release Notes

Code Generation Configuration Features

Diagnostics Pane Items Classified into Logical Groups

To make selecting diagnostics easier, the Diagnostics entries on the Simulation Parameters dialog have been reorganized according to functionality, and alphabetically within each group, as shown below.

Comments Not Generated for Reduced Blocks When "Show eliminated statements" Is Off

The Show eliminated statements option (in the Real-Time Workshop General code generation options category) is now off by default. As long as it remains off, Real-Time Workshop no longer generates comments referring to blocks that have been removed from the model via block reduction optimization.

New General Code Appearance Options

A new category has been added to the Real-Time Workshop dialog box, named General code appearance options. This pane adds four new code formatting options to two existing options that formerly occupied other categories. The General code appearance dialog is shown below.

The Maximum identifier length field allows you to limit the number of characters in function, typedef, and variable names. The default is 31 characters, but Real-Time Workshop imposes no upper limit.

Selecting Include data type acronym in identifier enables you to prepend acronyms such as i32 (for long integers) to signal and work vector identifiers to make code more readable. The default is not to include datatype acronyms in identifiers.

The Include system hierarchy number in identifiers option, when selected, prefixes s#_, where # is a unique integer subsystem index, to identifiers declared in that subsystem. This enhances traceability of code, for example via the hilite_system<`S#'> command. The default is not to include a system hierarchy index in identifiers.

The Prefix model name to global identifiers checkbox is a new option that is ON by default. When this option is on, Real-Time Workshop prefixes subsystem function names with the name of the model (model_). The model name is also prefixed to the names of functions and data structures at the model level, when appropriate to the code format. This is useful when you need to compile and link code from two or more models into a single executable, as it avoids potential name clashes.

You can now exercise control over the code style for inlined parameters through a new pull-down menu, Generate scalar inline parameters as: [literals | macros]. When constant parameters are inlined and declared not tunable, the following code generation options are available:

• Vector parameters were formerly stored as constant parameters in rtP vectors. Now they are declared as constant vectors of appropriate type, independent of rtP.
• Scalar parameters were formerly inlined as literals. In addition to this approach, users now have the option to have scalar parameters expressed as #define macro definitions.

The default is to generate scalar inline parameters as literals.

Note    S-functions can mark a run-time parameter as being constant in order to guarantee that it never ends up in the rtP data structure. Use ssSetConstRunTimeParamInfo in the S-function to register a constant run-time parameter.

Generate comments is an existing global option that was moved from the General code generation options (cont) category to this one. As in the prior release, the default for Generate comments is ON.

Identifier Construction for Generated Code Has Been Simplified

The methods which Real-Time Workshop uses to construct identifiers for variables and functions have been enhanced to make identifiers more understandable and more customizable. As a result of these enhancements

• Changes to sections of the model do not cause identifiers elsewhere to change.
• Reused function input arguments now derive their name from the inport block.
• Subsystem function names can be prefixed by the model name to prevent link errors due to name conflicts.
• Users may specify maximum identifier length (can be > 31 characters).
• A new option exists to include a datatype acronym in identifiers.
• Use of _a, _b, ... postfixes to identifiers to prevent name clashes has been dramatically reduced.

See also New General Code Appearance Options for related information.

GUI Control over Behavior of Assertion Blocks in Generated Code

The Advanced pane of the Simulation Parameters dialog shown above also provides you with a control 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, and also may be customized.

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 no-op 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'
  

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.

GUI Control Over TLC %assert Directive Evaluation

Prior versions required specifying the -da Target Language Compiler command switch in order for TLC %assert directives to be evaluated. Now users can more conveniently trigger %assert code by checking the Enable TLC Assertions box on the TLC debugging section of the Real-Time Workshop dialog page. The default state is for asserts not to be evaluated. You can also control assertion handling from the MATLAB command window:

set_param(model, 'TLCAssertion', 'on|off') to set or unset. Default is Off.

get_param(model, 'TLCAssertion') to see the current setting.

New Features and Enhancements

Block-level Enhancements