| Real-Time Workshop® Embedded Coder™ | |
The Real-Time Workshop Embedded Coder software features a number of code generation options that can help you further optimize the generated code. This section highlights code generation options you can use to improve performance and reduce code size.
Most of the tips in this section apply specifically to the ERT target. See also the Optimizing a Model for Code Generation section of the Real-Time Workshop documentation for optimization techniques that are common to all target configurations.
To make it easier for you to generate the most efficient code for your target CPU, the Real-Time Workshop Embedded Coder software provides two auto-optimized ERT target variants. These target variants are optimized, respectively, for fixed-point and floating-point code generation.
Before generating and deploying code, consider using one of these optimized target variants. The optimized ERT target variants are discussed in detail in Generating Efficient Code with Optimized ERT Targets.
The Real-Time Workshop Embedded Coder software provides a library of Configuration Wizard blocks and scripts to help you configure and optimize code generation from your models quickly and easily.
When you add one of the preset Configuration Wizard blocks to your model and double-click it, an M-file script executes and configures all parameters of the model's active configuration set without user intervention. The preset blocks configure the options optimally for common fixed- and floating-point code generation scenarios.
You can also create custom Configuration Wizard scripts and blocks.
See Optimizing Your Model with Configuration Wizard Blocks and Scripts for detailed information.
Correct specification of target-specific characteristics of generated code (such as word sizes for char, short, int, and long data types, or desired rounding behaviors in integer operations) can be critical in embedded systems development. The Hardware Implementation category of options in a configuration set provides a simple and flexible way to control such characteristics in both simulation and code generation.
Before generating and deploying code, you should become familiar with the options on the Hardware Implementation pane of the Configuration Parameters dialog box. See Hardware Implementation Pane in the Simulink documentation and Describing Hardware Properties in the Real-Time Workshop documentation for full details on the Hardware Implementation pane.
By configuring the Hardware Implementation properties of your model's active configuration set to match the behaviors of your compiler and hardware, you can generate more efficient code. For example, if you specify the Byte ordering property, you can avoid generation of extra code that tests the byte ordering of the target CPU.
You can use the rtwdemo_targetsettings demo model to determine some implementation-dependent characteristics of your C or C++ compiler, as well as characteristics of your target hardware. By using this model in conjunction with your target development system and debugger, you can observe the behavior of the code as it executes on the target. You can then use this information to configure the Hardware Implementation parameters of your model.
To use this model, type the command
rtwdemo_targetsettings
Follow the instructions in the model window.
Consider selecting the Remove internal data zero initialization and Remove root level I/O zero initialization options on the Optimization pane.
These options (both off by default) control whether internal data (block states and block outputs) and external data (root inports and outports whose value is zero) are initialized. Initializing the internal and external data whose value is zero is a precaution and may not be necessary for your application. Many embedded application environments initialize all RAM to zero at startup, making generation of initialization code redundant.
However, be aware that if you select Remove internal data zero initialization, it is not guaranteed that memory is in a known state each time the generated code begins execution. If you select the parameter, running a model (or a generated S-function) multiple times can result in different answers for each run.
This behavior is sometimes desirable. For example, you can turn on Remove internal data zero initialization if you want to test the behavior of your design during a warm boot (that is, a restart without full system reinitialization).
In cases where you have turned on Remove internal data zero initialization but still want to get the same answer on every run from a S-function generated by the Real-Time Workshop Embedded Coder software, you can use either of the following MATLAB commands before each run:
clear SFcnName
where SFcnName is the name of the S-function, or
clear mex
A related option, Use memset to initialize floats and doubles, lets you control the representation of zero used during initialization. See Use memset to initialize floats and doubles to 0.0 in the Simulink reference documentation.
Note that the code still initializes data structures whose value is not zero when Remove internal data zero initialization and Remove root level I/O zero initialization are selected.
Note also that data of ImportedExtern or ImportedExternPointer storage classes is never initialized, regardless of the settings of these options.
If your application uses only integer arithmetic, deselect the Support floating-point numbers option in the Software environment section of the Interface pane to ensure that generated code contains no floating-point data or operations. When this option is deselected, an error is raised if any noninteger data or expressions are encountered during code generation. The error message reports the offending blocks and parameters.
Clear the MAT-file logging option in the Verification section of the Interface pane. This setting is the default, and is recommended for embedded applications because it eliminates the extra code and memory usage required to initialize, update, and clean up logging variables. In addition to these efficiencies, clearing the MAT-file logging option lets you exploit further efficiencies under certain conditions. See Using Virtualized Output Ports Optimization for information.
Note also that code generated to support MAT-file logging invokes malloc, which may be undesirable for your application.
The virtualized output ports optimization lets you store the signal entering the root output port as a global variable. This eliminates code and data storage associated with root output ports when the MAT-file logging option is cleared and the TLC variable FullRootOutputVector equals 0, both of which are defaults for Real-Time Workshop Embedded Coder targets.
To illustrate this feature, consider the model shown in the following block diagram. Assume that the signal exportedSig has exportedGlobal storage class.
In the default case, the output of the Gain block is written to the signal storage location, exportedSig. No code or data is generated for the Out1 block, which has become, in effect, a virtual block. This is shown in the following code fragment.
/* Gain Block: <Root>/Gain */ exportedSig = rtb_PulseGen * VirtOutPortLogOFF_P.Gain_Gain;
In cases where either the MAT-file logging option is enabled, or FullRootOutputVector = 1, the generated code represents root output ports as members of an external outputs vector.
The following code fragment was generated from the same model shown in the previous example, but with MAT-file logging enabled. The output port is represented as a member of the external outputs vector VirtOutPortLogON_Y. The Gain block output value is copied to both exportedSig and to the external outputs vector.
/* Gain Block: <Root>/Gain */ exportedSig = rtb_PulseGen * VirtOutPortLogON_P.Gain_Gain; /* Outport Block: <Root>/Out1 */ VirtOutPortLogON_Y.Out1 = exportedSig;
The overhead incurred by maintenance of data in the external outputs vector can be significant for smaller models being used to perform benchmarks.
Note that you can force root output ports to be stored in the external outputs vector (regardless of the setting of MAT-file logging) by setting the TLC variable FullRootOutputVector to 1. You can do this by adding the statement
%assign FullRootOutputVector = 1
to the Real-Time Workshop Embedded Coder system target file. Alternatively, you can enter the assignment with TLC options on the Real-Time Workshop pane of the Configuration Parameters dialog box.
For more information on how to control signal storage in generated code, see the Working with Data section of the Real-Time Workshop documentation.
The Real-Time Workshop software offers a number of options that let you control how signals in your model are stored and represented in the generated code. This section discusses options that
Let you control whether signal storage is declared in global memory space, or locally in functions (that is, in stack variables).
Control the allocation of stack space when using local storage.
For a complete discussion of signal storage options, see the Working with Data section of the Real-Time Workshop documentation.
If you want to store signals in stack space, you must turn the Enable local block outputs option on. To do this
Select the Optimization tab of the Configuration Parameters dialog box. Make sure that the Signal storage reuse option is selected. If Signal storage reuse is off, the Enable local block outputs option is not available.
Select the Enable local block outputs option. Click Apply if necessary.
Your embedded application may be constrained by limited stack space. When the Enable local block outputs option is on, you can limit the use of stack space by using the following TLC variables:
MaxStackSize: The total allocation size of local variables that are declared by all block outputs in this model cannot exceed MaxStackSize (in bytes). MaxStackSize can be any positive integer. If the total size of local block output variables exceeds this maximum, the remaining block output variables are allocated in global, rather than local, memory. The default value for MaxStackSize is rtInf, that is, unlimited stack size.
Note Local variables in the generated code from sources other than local block outputs and stack usage from sources such as function calls and context switching are not included in the MaxStackSize calculation. For overall executable stack usage metrics, you should do a target-specific measurement, such as using runtime (empirical) analysis or static (code path) analysis with object code. |
MaxStackVariableSize: Limits the size of any local block output variable declared in the code to N bytes, where N>0. A variable whose size exceeds MaxStackVariableSize is allocated in global, rather than local, memory. The default is 4096.
To set either of these variables, use assign statements in the system target file (ert.tlc), as in the following example.
%assign MaxStackSize = 4096
You should write your %assign statements in the Configure RTW code generation settings section of the system target file. The %assign statement is described in the Target Language Compiler document.
Selecting the External mode option turns on generation of code to support external mode communication between host (the Simulink model) and target systems. Real-Time Workshop Embedded Coder software supports all features of Simulink external mode, as described in the External Mode section of the Real-Time Workshop documentation.
This section discusses external mode options that may be of special interest to embedded systems designers. The next figure shows the Data Exchange subpane of the Configuration Parameters dialog box, Interface pane, with External mode selected.
Consider the Memory management option Static memory allocation before generating external mode code for an embedded target. Static memory allocation is generally desirable, as it reduces overhead and promotes deterministic performance.
When you select the Static memory allocation option, static external mode communication buffers are allocated in the target application. When Static memory allocation is deselected, communication buffers are allocated dynamically (with malloc) at run time.
Real-Time Workshop Embedded Coder software supports generation of pure integer code when external mode code is generated. To do this, select the External mode option, and deselect the Support floating-point numbers option in the Software environment section of the Interface pane.
This enhancement lets you generate external mode code that is free of any storage definitions of double or float data type, and allows your code to run on integer-only processors
If you intend to generate pure integer code with External mode on, note the following requirements:
All trigger signals must be of data type int32. Use a Data Type Conversion block if needed.
When pure integer code is generated, the simulation stop time specified in the Solver options is ignored. To specify a stop time, run your target application from the MATLAB command line and use the -tf option. (See Running the External Program in the "External Mode" section of the Real-Time Workshop documentation.) If you do not specify this option, the application executes indefinitely (as if the stop time were inf).
When executing pure integer target applications, the stop time specified by the -tf command line option is interpreted as the number of base rate ticks to execute, rather than as an elapsed time in seconds. The number of ticks is computed as
stop time in seconds / base rate step size in seconds
| Configuring a Model | Creating and Using a Code Generation Report | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |