Real-Time Workshop 5.0 Release Notes (Real-Time Workshop Release Notes)

Real-Time Workshop Release Notes

New Features and Enhancements

This section introduces the new features and enhancements added in the Real-Time Workshop 5.0 since the Real-Time Workshop 4.1. A number of enhancements to Simulink that can impact code generation are also described.

For information about Real-Time Workshop features that are incorporated from recent releases, see the Real-Time Workshop 4.1 Release Notes and the Real-Time Workshop 4.0 Release Notes documentation.

Note For information about closely related products that extend the Real-Time Workshop, see the Release Notes sections about the Real-Time Workshop Embedded Coder and the xPC Target.

Code Generation Infrastructure Enhancements

Code for Nonvirtual Subsystems Is Now Reusable

Real-Time Workshop 5.0 alters certain aspects of generated code to implement the capability to reuse code for nonvirtual subsystems. You have the ability to select or override this feature, as well as to specify function and file names from the Real-time Workshop GUI.

In prior releases, each nonvirtual subsystem in a model generated a separate block of code. In some circumstances--for example, when a library block is used multiple times in the same fashion--it is possible to generate a single shared function for the block and call that function multiple times. Consolidating code in this fashion can significantly improve the size and efficiency of generated code.

To implement code reuse, the Real-Time Workshop must pass in appropriate data elements (as function arguments) for each caller of a reused subsystem. Code generated by Real-Time Workshop 5.0 enables such arguments for functions generated for nonvirtual subsystems.

You enable code reuse through the Subsystem parameters dialog box when both Treat as atomic unit and Reusable function from the RTW system code pull-down menu are selected, as illustrated below.

Reusable code will also be generated, when feasible, when you set RTW system code to Auto. Then, if only one instance of the subsystem exists, it will be inlined; otherwise a reusable function will be generated if other characteristics of the model allow this.

Certain conditions may make it impossible to reuse code, causing Real-Time Workshop to revert to another RTW system code option even though you specify Reusable function or Auto. When Reusable function is specified and reuse is not possible, the result will be a function without arguments. When Auto is specified and reuse is not possible, the result will be to inline the subsystem's code (or in special cases, create a function without arguments). Diagnostics are available in the HTML code generation report (if enabled; see "Generate HTML Report Option Available for Additional Targets") to help identify the reasons why reuse is not occurring in particular instances. In addition to providing these exception diagnostics, the HTML report's Subsystems section also maps each noninlined subsystem in the model to functions or reused functions in the generated code.

Requirements for Generation of Reusable Code from Stateflow Charts. To generate reusable code from a Stateflow chart, or from a subsystem containing a Stateflow chart, all of the following conditions must be met:

The chart (or subsystem containing the chart) must be a library block (see "Working with Block Libraries" in the Simulink documentation).
Data in the chart must not be initialized from workspace. The data property Initialize from workspace should be off.
The chart must not output a function call.

See Nonvirtual Subsystem Code Generation in the Real Time Workshop documentation for further details.

Packaging of Generated Code Files Simplified

The packaging of generated code into.c and.h files has changed. The following table summarizes the structure of source code generated by the Real-Time Workshop. All code modules described are written to the build directory.

Note The file packaging of the Real-Time Workshop Embedded Coder differs slightly (but significantly) from the file packaging described here. See the "Data Structures and Code Modules" section in the Real-Time Workshop Embedded Coder User's Guide for further information.

Table 1-1: Real-Time Workshop File Packaging
File
Description

model.c
Contains entry points for all code implementing the model algorithm (MdlStart, MdlOutputs, MdlUpdate, MdlInitializeSizes, MdlInitializeSampleTimes). Also contains model registration code.

model_private.h
Contains local defines and local data that are required by the model and subsystems. This file is included by subsystem.c files in the model. You do not need to include model_private.h when interfacing hand-written code to a model.
Note that model_private.h is sub-included by model.h.

model.h
Defines model data structures and a public interface to the model entry points and data structures. Also provides an interface to the real-time model data structure (model_rtM) via accessor macros. model.h is included by subsystem.c files in the model.
If you are interfacing your hand-written code to generated code for one or more models, you should include model.h for each model to which you want to interface.

model_data.c (conditional)
model_data.c is conditionally generated. It contains the declarations for the parameters data structure and the constant block I/O data structure. If these data structures are not used in the model, model_data.c is not generated. Note that these structures are declared extern in model.h.

model_types.h
Provides forward declarations for the real-time model data structure and the parameters data structure. These may be needed by function declarations of reusable functions. model_types.h is included by all subsystem.h files in the model.

rtmodel.h
Contains #include directives required by static main program modules such as grt_main.c and grt_malloc_main.c. Since these modules are not created at code generation time, they include rt_model.h to access model-specific data structures and entry points. If you create your own main program module, take care to include rtmodel.h.

model_pt.c(optional)
Provides data structures that enable a running program to access model parameters without use of external mode. To learn how to generate and use the model_pt.c file, see C API for Parameter Tuning."

model_bio.c(optional)
Provides data structures that enable your code to access block outputs. To learn how to generate and use the model_bio.c file, see Signal Monitoring via Block Outputs."

Table 1-1: **Real-Time Workshop File Packaging**
File	Description
`model.c`	Contains entry points for all code implementing the model algorithm (`MdlStart`, `MdlOutputs`, `MdlUpdate`, `MdlInitializeSizes`, `MdlInitializeSampleTimes`). Also contains model registration code.
`model_private.h`	Contains local defines and local data that are required by the model and subsystems. This file is included by `subsystem.c` files in the model. You do not need to include `model_private.h` when interfacing hand-written code to a model. Note that `model_private.h` is sub-included by `model.h`.
`model.h`	Defines model data structures and a public interface to the model entry points and data structures. Also provides an interface to the real-time model data structure (`model_rtM`) via accessor macros. `model.h` is included by `subsystem.c` files in the model. If you are interfacing your hand-written code to generated code for one or more models, you should include `model.h` for each model to which you want to interface.
`model_data.c (conditional)`	`model_data.c` is conditionally generated. It contains the declarations for the parameters data structure and the constant block I/O data structure. If these data structures are not used in the model, `model_data.c` is not generated. Note that these structures are declared `extern` in `model.h`.
`model_types.h`	Provides forward declarations for the real-time model data structure and the parameters data structure. These may be needed by function declarations of reusable functions. `model_types.h` is included by all `subsystem.h` files in the model.
`rtmodel.h`	Contains `#include` directives required by static main program modules such as `grt_main.c` and `grt_malloc_main.c`. Since these modules are not created at code generation time, they include `rt_model.h` to access model-specific data structures and entry points. If you create your own main program module, take care to include `rtmodel.h`.
`model_pt.c`(optional)	Provides data structures that enable a running program to access model parameters without use of external mode. To learn how to generate and use the `model_pt.c` file, see C API for Parameter Tuning."
`model_bio.c`(optional)	Provides data structures that enable your code to access block outputs. To learn how to generate and use the `model_bio.c` file, see Signal Monitoring via Block Outputs."

If you have interfaced hand-written code to code generated by previous releases of the Real-Time Workshop, you may need to remove dependencies on header files that are no longer generated. Use #include model.h directives, and remove #include directives referencing any of the following:

model_common.h (replaced by model_types.h and model_private.h)
model_export.h (replaced by model.h)
model_prm.h (replaced by model_data.c)
model_reg.h (subsumed by model.c)

Most Targets Use rtModel Instead of Root SimStruct

The GRT, GRT-Malloc, ERT, and Tornado targets now use the rtModel data structure to store information about the root model. In prior releases, this information was stored in the SimStruct data structure. Since the SimStruct data structure was also used by non-inlined S-functions, it contained a number of S-function-specific fields that were not needed to represent root model information. The new rtModel is a lightweight data structure that eliminates these unused fields in representing the root model. Fields in the rtModel capture model-wide information pertaining to timing, solvers, logging, model data (such as block I/O, and DWork, parameters), etc. To generate code for the ERT target, the rtModel data structure is further pruned to contain only those fields that are relevant to the model under consideration.

Note If you have previously customized GRT, GRT-Malloc, or Tornado targets, you should upgrade each customized target to use the rtModel instead of the SimStruct. You can find guidelines for this upgrade path in Upgrading Customized GRT and GRT-Malloc Targets to Work with Release 13.

Hook Files for Communicating Target-specific Word Characteristics

In order to communicate details about target hardware characteristics, such as word lengths and overflow behavior, you now need to supply an M-file named <target>_rtw_info_hook.m. Each system target file needs to implement a hook file. For GRT (grt.tlc), for example, the file must be named grt_rtw_info_hook.m, and needs to be on the MATLAB path. If the hookfile is not provided, default values based on the host's characteristics will be used, which may not be appropriate. For an example, see toolbox/rtw/rtwdemos/example_rtw_info_hook.m. In addition, note that the TLC directive %assign DSP = 1 no longer has any effect. You need to provide a hook file instead.

Code Generation Unified for Real-Time Workshop and Stateflow

In earlier releases, code generated from Stateflow charts in a model was written to source code files distinct from the source code files (such as model.c, model.h, etc.) generated from the rest of the model.

Now, by default, Stateflow no longer generates any separate files from the Real-Time Workshop. In addition, Stateflow generated code is seamlessly integrated with other generated code. For example, all Stateflow initialization code is now inlined.

You can override the default and instruct the Real-Time Workshop to generate separate functions, within separate code files, for a Stateflow chart. To do this, use the RTW system code options in the Block parameters dialog of the Stateflow chart (see Nonvirtual Subsystem Code Generation in the Real-Time Workshop documentation). You can control both the names of the functions and of the code files generated.

Conditional Input Branch Execution Optimization

This release introduces a new optimization called conditional input branch execution, speeding simulation and execution of code generated from the model. Previously, when simulating models containing Switch or Multiport Switch blocks, Simulink executed all blocks required to compute all inputs to each switch at each time step. In this release, Simulink, by default, executes only the blocks required to compute the control input and the data input selected by the control input at each time step. Likewise, standalone applications generated from the model by Real-Time Workshop execute only the code needed to compute the control input and the selected data input. To explore this feature, look at the coninputexec demo.

Real-Time Workshop 5.0 Release Notes Code Generation Configuration Features