Model Reference Simulation Targets :: Referencing a Model (Simulink®)

A simulation target, or SIM target, is a MEX-file that implements a referenced model that executes in Accelerator mode. Simulink invokes the simulation target as needed during simulation to compute the behavior and outputs of the referenced model. Simulink uses the same simulation target for all Accelerator mode instances of a given referenced model anywhere in a reference hierarchy.

Be careful not to confuse the simulation target of a submodel with any of these other types of target:

Hardware target — A platform for which Simulink Coder generates code
System target — A file that tells Simulink Coder how to generate code for particular purpose
Rapid Simulation target (RSim) — A system target file supplied with Simulink Coder
Model reference target — A library module that contains Simulink Coder code for a referenced model

Simulink creates a simulation target only for a submodel that has one or more Accelerator mode instances in a reference hierarchy. A submodel that executes only in Normal mode always executes interpretively and does not use a simulation target. When one or more instance of a submodel executes in Normal mode, and one or more instance executes in Accelerator mode:

Simulink creates a simulation target for the Accelerator mode instances.
The Normal mode instances do not use that simulation target.

Because Accelerator mode requires code generation, it imposes some requirements and limitations that do not apply to Normal mode. Aside from these constraints, you can generally ignore simulation targets and their details when you execute a referenced model in Accelerator mode. See Limitations on Accelerator Mode Referenced Models for details.

Building Simulation Targets

Simulink by default generates the needed target from the referenced model:

If a simulation target does not exist at the beginning of a simulation
When you perform an update diagram for a parent model

If the simulation target already exists, then by default Simulink checks whether the submodel has structural changes since the target was last generated. If so, Simulink regenerates the target to reflect changes in the model. For details about how Simulink detects whether to rebuild a model reference target, see the Rebuild parameter documentation.

You can change this default behavior to modify the rebuild criteria or specify that Simulink always or never rebuilds targets. See Rebuild for details.

To generate simulation targets interactively for Accelerator mode referenced models, do one of these steps:

Update the diagram on a model that directly or indirectly references the model that is in Accelerator mode
Execute the slbuild command with appropriate arguments at the MATLAB command line

While generating a simulation target, Simulink displays status messages at the MATLAB command line to enable you to monitor the target generation process. Target generation entails generating and compiling code and linking the compiled target code with compiled code from standard code libraries to create an executable file.

Reducing Change Checking Time

You can reduce the time that Simulink spends checking whether any or all simulation targets require rebuilding by setting configuration parameter values as follows:

In all referenced models throughout the hierarchy, set Configuration Parameters > Diagnostics > Data Validity > Signal resolution to Explicit only. (See Signal resolution.)
To minimize change detection time, consider setting Configuration Parameters > Model Referencing > Rebuild options to If any changes in known dependencies detected on the top model. See Rebuild.

These parameter values exist in the configuration set of a referenced model, not in the individual Model block, so setting either value for any instance of a referenced model sets it for all instances of that model.

Simulation Target Output File Control

Simulink creates simulation targets in the slprj subfolder of the working folder. If slprj does not exist, Simulink creates it.

Note Simulink Coder code generation also uses the slprj folder. Subdirectories in slprj provide separate places for simulation code, Simulink Coder code, and other files. For details, see .

By default, the files generated by Simulink diagram updates and model builds are placed in a build folder, the root of which is the current working folder (pwd). However, in some situations, you might want the generated files to go to a root folder outside the current working folder. For example:

You need to keep generated files separate from the models and other source materials used to generate them.
You want to reuse or share previously-built simulation targets without having to set the current working folder back to a previous working folder.

You might also want to separate generated simulation artifacts from generated production code.

To allow you to control the output locations for the files generated by diagram updates and model builds, the software allows you to separately specify the simulation cache folder build folder. The simulation cache folder is the root folder in which to place artifacts used for simulation.

To specify the simulation cache folder, use one of these approaches:

Use the CacheFolder MATLAB session parameter.
Open the Simulink Preferences dialog box (File > Preferences) and specify a location on your file system for the Simulation cache folder, which, if specified, provides the initial defaults for the MATLAB session parameters.

Controlling the Output Location for Model Build Artifacts Used for Simulation

The Simulink preference Simulation cache folder provides control over the output location for files generated by Simulink diagram updates. The preference appears in the Simulink Preferences Window, Main Pane, in the File generation control group. To specify the root folder location for files generated by Simulink diagram updates, set the preference value by entering or browsing to a folder path, for example:

The folder path that you specify provides the initial default for the MATLAB session parameter CacheFolder. When you initiate a Simulink diagram update, any files generated are placed in a build folder at the root location specified by CacheFolder (if any), rather than in the current working folder (pwd).

For example, using a 32-bit Windows host platform, if you set the Simulation cache folder to 'C:\Work\mymodelsimcache' and then simulate the demo model rtwdemo_capi, files are generated into the specified folder as follows:

As an alternative to using the Simulink preferences GUI to set Simulation cache folder, you also can get and set the preference value from the command line using get_param and set_param. For example,

>> get_param(0, 'CacheFolder')

ans =

     ''

>> set_param(0, 'CacheFolder', fullfile('C:','Work','mymodelsimcache'))
>> get_param(0, 'CacheFolder')

ans =

C:\Work\mymodelsimcache

Also, you can choose to override the Simulation cache folder preference value for the current MATLAB session.

Overriding Build Folder Settings for the Current MATLAB Session

The Simulink preferences Simulation cache folder and Code generation folder provide the initial defaults for the MATLAB session parameters CacheFolder and CodeGenFolder, which determine where files generated by Simulink diagram updates and model builds are placed. However, you can override these build folder settings during the current MATLAB session, using the Simulink.fileGenControl function. This function allows you to directly manipulate the MATLAB session parameters, for example, overriding or restoring the initial default values. The values you set using Simulink.fileGenControl expire at the end of the current MATLAB session. For more information and detailed examples, see the Simulink.fileGenControl function reference page.

Parallel Building for Large Model Reference Hierarchies

In a parallel computing environment, you can increase the speed of diagram updates for models containing large model reference hierarchies by building referenced models that are configured in Accelerator mode in parallel whenever conditions allow. For example, if you have Parallel Computing Toolbox™ software, updating of each referenced model can be distributed across the cores of a multicore host computer. If you additionally have MATLAB^® Distributed Computing Server™ (MDCS) software, updating of each referenced model can be distributed across remote workers in your MATLAB Distributed Computing Server configuration.

To take advantage of parallel building for a model reference hierarchy:

Set up a pool of local and/or remote MATLAB workers in your parallel computing environment.
1. Make sure that Parallel Computing Toolbox software is licensed and installed.
2. To use remote workers, make sure that MATLAB Distributed Computing Server software is licensed and installed.
3. Issue appropriate MATLAB commands to set up the worker pool, for example, matlabpool 4.
In the Configuration Parameters dialog box, go to the Model Referencing pane and select the Enable parallel model reference builds option. This selection enables the parameter MATLAB worker initialization for builds.

For MATLAB worker initialization for builds, select one of the following values:
- None if the software should perform no special worker initialization. Specify this value if the child models in the model reference hierarchy do not rely on anything in the base workspace beyond what they explicitly set up (for example, with a model load function).
- Copy base workspace if the software should attempt to copy the base workspace to each worker. Specify this value if you use a setup script to prepare the base workspace for all models to use.
- Load top model if the software should load the top model on each worker. Specify this value if the top model in the model reference hierarchy handles all of the base workspace setup (for example, with a model load function).
Optionally, inspect the model reference hierarchy to determine, based on model dependencies, which models will be built in parallel. For example, you can use the Model Dependency Viewer from the Simulink Tools menu.
Update your model. Messages in the MATLAB command window record when each parallel or serial build starts and finishes.

The performance gain realized by using parallel builds for updating referenced models depends on several factors, including how many models can be built in parallel for a given model referencing hierarchy, the size of the referenced models, and parallel computing resources such as number of local and/or remote workers available and the hardware attributes of the local and remote machines (amount of RAM, number of cores, and so on).

The following notes apply to using parallel builds for updating model reference hierarchies:

For local pools, the host machine should have an appropriate amount of RAM available for supporting the number of local workers (MATLAB sessions) that you plan to use. For example, setting matlabpool to 4 results in five MATLAB sessions on your machine, each using approximately 120 MB of memory at startup.
Remote MDCS workers participating in a parallel build must use a common platform and compiler.
A consistent MATLAB environment must be set up in each MATLAB worker session as in the MATLAB client session — for example, all shared base workspace variables, MATLAB path settings, and so forth. One approach is to use the PreLoadFcn callback of the top model. If you configure your model to load the top model with each MATLAB worker session, its preload function can be used for any MATLAB worker session setup.

Viewing a Model Reference Hierarchy

Simulink Model Referencing Requirements

Related Products & Applications

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit

Search MATLAB Documentation
R2011b Documentation → Simulink
View documentation for other releases	Learn more about Simulink