Design Your Model for Effective Acceleration

Accelerator and rapid accelerator mode speed up simulation execution by generating a simulation target from the model. The accelerator simulation target provides performance gains while balancing flexibility and interactivity with the model during simulation. The rapid accelerator simulation target provides the most performant execution but less flexibility and interactivity.

In general, accelerator mode limitations do not prevent simulation but might reduce the performance benefit of using accelerator mode. On the other hand, rapid accelerator mode provides consistent performance benefit but limitations can require modifying your model in order to run a rapid accelerator simulation.

Select Blocks for Accelerator Mode

The blocks in your model affect how much using accelerator mode improves performance. Accelerator mode does not optimize the way all blocks execute during simulation. If your model contains many of these blocks, accelerator mode might not improve performance significantly compared to normal mode:

• Display block

• From File block

• From Workspace block

• Top-level Inport block

• Interpreted MATLAB Function block

• Top-level Outport block

• Scope block

• To File block

• To Workspace block

These blocks can cause poor simulation runtime performance when run in the default JIT accelerator mode.

• Transport Delay block

• Variable Transport Delay block

Select Blocks for Rapid Accelerator Mode

These blocks are not supported for rapid accelerator simulations:

• Blocks that do not support code generation, such as SimEvents^® blocks

• Blocks that generate code for only specific targets

• Interpreted MATLAB Function blocks

• Device driver S-functions, such as blocks from the Simulink^® Real-Time™ product, or blocks that target Freescale^® MPC555

Control S-Function Execution

Note

In the default JIT accelerator mode, inlining custom TLC S-functions is not supported. If you simulate a model that contains TLC S-functions in the JIT accelerator mode, the execution speed might decrease. However, JIT acceleration still speeds up generation of the accelerator simulation target.

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 software runs on the host system rather than the target, it cannot access the target 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 */
ssSetOptions(S, SS_OPTION_USE_TLC_WITH_ACCELERATOR);
}

Rapid accelerator mode uses the MEX file if the S-Function C file is not present in the same folder.

Note

To use the .c or .cpp code for your S-function, ensure that the files are in the same folder as the S-function MEX file. Otherwise, you can include additional files in 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).

Data Type Considerations for Accelerator and Rapid Accelerator Simulations

• Accelerator simulations support fixed-point signals and vectors up to 65,535 bits.

• Rapid accelerator simulations support:

  • Fixed-point parameters up to 65,535 bits

  • Using top-level input ports to load enumerated data and fixed-point data up to 32 bits

• Rapid accelerator simulations do not support loading fixed-point data using the From Workspace block.

• Rapid accelerator simulations ignore the Log fixed-point data as a fi object parameter of the To Workspace block.

• Rapid accelerator simulations support bus objects as parameters.

• Accelerator and rapid accelerator simulations store integers as compactly as possible.

• Fixed-Point Designer™ does not collect min, max, or overflow data in accelerator or rapid accelerator simulations.

• Accelerator and rapid accelerator simulations support a limited set of runtime diagnostics, including assertion blocks.

Behavior of Scopes and Viewers in Rapid Accelerator Simulations

The behavior of scopes and viewers in rapid accelerator simulations depends on whether you run the simulation programmatically or from a user interface, such as the Simulink Editor. For more information, see Run Acceleration Mode from the User Interface and Interact with the Acceleration Modes Programmatically.

Scope or Viewer Type	Simulation Run Interactively	Simulation Run Programmatically
Simulink Scope block	Same support as normal mode	Logging is supported Scope window is not updated
Simulink signal viewer scopes	Graphics are updated, but logging is not supported	Not supported
Other signal viewer scopes	Support limited to that available in external mode	Not supported
Viewers that stream logged data during simulation, such as the Simulation Data Inspector and the Logic Analyzer	Data not visualized during simulation	Data not visualized during simulation
Stateflow® charts	Same support for chart animation as normal mode	Not supported

Factors That Prevent Acceleration

• You cannot use accelerator mode 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 that contain trigonometric functions that have complex inputs.

• In some cases, accelerator and rapid accelerator simulation results do not reflect changes to external or custom code, such as:

  • TLC code

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

  • Integrated custom code

  • S-Function Builder

  In such cases, consider forcing a rebuild of the simulation target for the top model, for example, by deleting the slprj folder.

  Note

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

Rapid Accelerator Limitations

• Rapid accelerator mode does not support:

  • Before R2026a: Models that contain algebraic loops.

  • 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).

  • Debugging utilities or the Simulink Profiler.

  • Block runtime objects, such as the Simulink.RunTimeBlock object.

  • Systems that run RHEL / CentOS 6.x or 7.x.

  • Printing messages to the MATLAB Command Window.

• Numeric values that define model parameters, block parameters, and variables in a model must have one of these data types:

  • boolean

  • uint8 or int8

  • uint16 or int16

  • uint32 or int32

  • single or double

  • Fixed-point

  • Enumerated

• Rapid accelerator simulations do not apply minimum and maximum output values specified for:

  • Top-level input ports

  • Simulink.Parameter objects used to define variable or parameter values

• To File and To Workspace blocks inside function-call subsystems do not generate logging files if the function-call port is unconnected or connected to a Ground block.

• Custom code that uses buses or custom enumerations is not fully supported in rapid accelerator simulations.

  • Rapid accelerator simulations can produce unexpected simulation results if custom code uses structures that represent buses or custom enumerations.

  • If the custom code includes type definitions for buses or custom enumerations, building the rapid accelerator simulation target might result in duplicate type definitions for these structures. If building the simulation target causes duplicate type definitions, the software issues an error.

• When you use a structure to define parameter values, tuned parameter values specified for rapid accelerator simulations must be smaller than 2 kB.

• Tuning Simulink.LookupTable objects is not supported in rapid accelerator simulations that disable the up-to-date check.

• Scopes do not display all data points for Simulink Function blocks, function-call subsystems, and iterator subsystems.

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. If you use these reserved keywords, the software issues an error and cannot compile or simulate the model.

The keywords reserved for the Simulink Coder product are listed in Construction of Generated Identifiers (Simulink Coder). The table summarizes additional keywords that apply only to accelerator and rapid accelerator simulations.

muDoubleScalarAbs	muDoubleScalarCos	muDoubleScalarMod
muDoubleScalarAcos	muDoubleScalarCosh	muDoubleScalarPower
muDoubleScalarAcosh	muDoubleScalarExp	muDoubleScalarRound
muDoubleScalarAsin	muDoubleScalarFloor	muDoubleScalarSign
muDoubleScalarAsinh	muDoubleScalarHypot	muDoubleScalarSin
muDoubleScalarAtan	muDoubleScalarLog	muDoubleScalarSinh
muDoubleScalarAtan2	muDoubleScalarLog10	muDoubleScalarSqrt
muDoubleScalarAtanh	muDoubleScalarMax	muDoubleScalarTan
muDoubleScalarCeil	muDoubleScalarMin	muDoubleScalarTanh