This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English verison of the page.

Note: This page has been translated by MathWorks. Please click here
To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

Design Your Model for Effective Acceleration

Select Blocks for Accelerator Mode

The Accelerator simulation mode runs the following blocks as if you were running Normal mode because these blocks do not generate code for the accelerator build. Consequently, if your model contains a high percentage of these blocks, the Accelerator mode may not increase performance significantly. All of these Simulink® blocks use interpreted code.

    Note:   In some instances, Normal mode output might not precisely match the output from Accelerator mode because of slight differences in the numerical precision between the interpreted and compiled versions of a model.

The following blocks can cause poor simulation runtime performance when run in the default JIT Accelerator mode.

Select Blocks for Rapid Accelerator Mode

Blocks that do not support code generation (such as SimEvents®) or blocks that generate code only for a specific target cannot be simulated in Rapid Accelerator mode.

Additionally, Rapid Accelerator mode does not work if your model contains any of the following blocks:

  • Interpreted MATLAB Function

  • Device driver S-functions, such as blocks from the Simulink Real-Time™ product, or those targeting Freescale™ MPC555

    Note:   In some instances, Normal mode output might not precisely match the output from Rapid Accelerator mode because of slight differences in the numerical precision between the interpreted and compiled versions of a model.

Control S-Function Execution

    Note:   In the default JIT Accelerator mode, inlining of user-written TLC S-Functions is not supported. If you run a model containing TLC S-Functions in the JIT Accelerator mode, there is a possibility of the execution speed reducing. The code generation speed, however, will be high due to JIT acceleration.

Inlining S-functions using the Target Language Compiler increases performance with the classic Accelerator mode by eliminating unnecessary calls to the Simulink API. By default, however, the classic Accelerator mode ignores an inlining TLC file for an S-function, even though the file exists. The Rapid Accelerator mode always uses the TLC file if one is available.

A device driver S-Function block written to access specific hardware registers on an I/O board is one example of why this behavior was chosen as the default. Because the Simulink software runs on the host system rather than the target, it cannot access the targets I/O registers and so would fail when attempting to do so.

To direct the classic Accelerator mode to use the TLC file instead of the S-function MEX-file, specify SS_OPTION_USE_TLC_WITH_ACCELERATOR in the mdlInitializeSizes function of the S-function, as in this example:

static void mdlInitializeSizes(SimStruct *S)
/* Code deleted */

The Rapid Accelerator mode will make use of the MEX file if the S-Function's C file is not present in the same folder.

    Note:   to use the .c or .cpp code for your S-Function, ensure that they are in the same folder as the S-Function MEX-file, otherwise, you can include additional files to an S-function or bypass the path limitation by using the rtwmakecfg.m file. For more information, see Use rtwmakecfg.m API to Customize Generated Makefiles (Simulink Coder).

Accelerator and Rapid Accelerator Mode Data Type Considerations

  • Accelerator mode supports fixed-point signals and vectors up to 128 bits.

  • Rapid Accelerator mode does not support fixed-point signals or vectors greater than 32 bits.

  • Rapid Accelerator mode supports fixed-point parameters up to 128 bits.

  • Rapid Accelerator mode supports fixed-point root inputs up to 32 bits

  • Rapid Accelerator mode supports root inputs of Enumerated data type

  • Rapid Accelerator mode does not support fixed-point data for the From Workspace block.

  • Rapid Accelerator mode ignores the selection of the Log fixed-point data as a fi object (FixptAsFi) check box for the To Workspace block.

  • Rapid Accelerator mode supports bus objects as parameters.

  • The Accelerator mode and Rapid Accelerator mode store integers as compactly as possible.

  • Fixed-Point Designer™ does not collect min, max, or overflow data in the Accelerator or Rapid Accelerator modes.

  • Accelerator mode does not support runtime diagnostics.

Behavior of Scopes and Viewers with Rapid Accelerator Mode

Running the simulation from the command line or the menu determines the behavior of scopes and viewers in Rapid Accelerator mode.

Scope or Viewer TypeSimulation Run from MenuSimulation Run from Command Line
Simulink Scope blocksSame support as Normal mode
  • Logging is supported

  • Scope window is not updated

Simulink signal viewer scopesGraphics are updated, but logging is not supportedNot supported
Other signal viewer scopesSupport limited to that available in External modeNot supported
Signal loggingSupported, with limitations listed in Signal Logging in Rapid Accelerator ModeSupported, with limitations listed in Signal Logging in Rapid Accelerator Mode.
Multirate signal viewersNot supportedNot supported
Stateflow® Chart blocksSame support for chart animation as Normal modeNot supported

Rapid Accelerator mode does not support multirate signal viewers such as the DSP System Toolbox™ spectrum scope or the Communications System Toolbox™ scatterplot, signal trajectory, or eye diagram scopes.

Factors Inhibiting Acceleration

  • You cannot use the Accelerator or Rapid Accelerator mode if your model:

    • Passes array parameters to MATLAB® S-functions that are not numeric, logical, or character arrays, are sparse arrays, or that have more than two dimensions.

    • Uses Fcn blocks containing trigonometric functions having complex inputs.

  • In some cases, changes associated with external or custom code do not cause Accelerator or Rapid Accelerator simulation results to change. These include:

    • TLC code

    • S-function source code, including rtwmakecfg.m files

    • Integrated custom code

    • S-Function Builder

    In such cases, consider force regeneration of code for a top model. Alternatively, you can force regeneration of top model code by deleting code generation folders, such as slprj or the generated model code folder.

      Note:   With JIT acceleration, the acceleration target code is in memory. It is therefore available for reuse as long as the model is open, even if you delete the slprj folder.

Rapid Accelerator Mode Limitations

  • Rapid Accelerator mode does not support:

    • Algebraic loops.

    • Targets written in C++.

    • Interpreted MATLAB Function blocks.

    • Noninlined MATLAB language or Fortran S-functions. You must write S-functions in C or inline them using the Target Language Compiler (TLC) or you can also use the MEX file. For more information, see Write Fully Inlined S-Functions (Simulink Coder).

    • 3-D signals.

    • Debugger or Profiler.

    • Run time objects for Simulink.RunTimeBlock and Simulink.BlockCompOutputPortData blocks.

  • Model parameters must be one of these data types:

    • boolean

    • uint8 or int8

    • uint16 or int16

    • uint32 or int32

    • single or double

    • Fixed-point

    • Enumerated

  • You cannot pause a simulation in Rapid Accelerator mode.

  • If a Rapid Accelerator build includes referenced models (by using Model blocks), set up these models to use fixed-step solvers to generate code for them. The top model, however, can use a variable-step solver as long as the blocks in the referenced models are discrete.

  • In certain cases, changing block parameters can result in structural changes to your model that change the model checksum. An example of such a change is changing the number of delays in a DSP simulation. In these cases, you must regenerate the code for the model. See Code Regeneration in Accelerated Models for more information.

  • For root inports, Rapid Accelerator mode supports only base as the Srcworkspace.

  • For root inports, when you specify the minimum and maximum values that the block should output, Rapid Accelerator mode does not recognize these limits during simulation.

  • In Rapid Accelerator mode, To File or To Workspace blocks inside function-call subsystems do not generate any logging files if the function-call port is grounded or unconnected.

Reserved Keywords

Certain words are reserved for use by the Simulink Coder™ code language and by Accelerator mode and Rapid Accelerator mode. These keywords must not appear as function or variable names on a subsystem, or as exported global signal names. Using the reserved keywords results in the Simulink software reporting an error, and the model cannot be compiled or run.

The keywords reserved for the Simulink Coder product are listed in Construction of Generated Identifiers (Simulink Coder). Additional keywords that apply only to the Accelerator and Rapid accelerator modes are:

muDoubleScalarAbs muDoubleScalarCosmuDoubleScalarMod
muDoubleScalarAcos muDoubleScalarCoshmuDoubleScalarPower
muDoubleScalarAsinh muDoubleScalarHypotmuDoubleScalarSin
muDoubleScalarCeil muDoubleScalarMin muDoubleScalarTanh

Related Examples

More About

Was this topic helpful?