Rebuild

Option to conditionally, always, or never rebuild model reference targets

Model Configuration Pane: Model Referencing

Description

The Rebuild configuration parameter determines when to rebuild simulation and Simulink^® Coder™ targets for referenced models before updating, simulating, or generating code from the model.

Models in a model hierarchy can have different rebuild settings. When you update, simulate, or generate code for a model, the rebuild setting for that model applies to all its referenced models.

Models that execute in normal mode do not generate simulation targets and are unaffected by the Rebuild settings.

Set Configuration Parameter for Referenced Model

In a model reference hierarchy, how you open the Configuration Parameters dialog box determines whether you edit the configuration parameter for the top model in the current model hierarchy or the current referenced model.

• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click Model Settings.

• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model Settings button arrow. Then, in the Referenced Model section, select Model Settings.

Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the Modeling tab, click Model Settings.

Settings

If changes detected (default) | Always | If changes in known dependencies detected | Never

Always

Always rebuild targets for referenced models. This setting requires the most processing time because it can trigger unnecessary builds. To make all model reference targets up to date, use this setting before you deploy a model.

If changes detected

Conditionally rebuild targets for referenced models when the software detects a change that could affect simulation results. To perform extensive change detection on dependencies of referenced models, use this setting.

If the software finds no changes in known dependencies, it computes the structural checksum of the model. The structural checksum detects changes that occur in user-created dependencies that are not specified using the Model dependencies configuration parameter. If the structural checksum has changed, the software rebuilds the model reference target.

If changes in known dependencies detected

Conditionally rebuild targets for referenced models when the software detects a change that could affect simulation results. To reduce the time required for change detection, use this setting.

If the software finds no changes in known or potential dependencies, it does not compute the structural checksum of the model and does not rebuild the model reference target. To avoid invalid simulation results, you must list all user-created dependencies in the Model dependencies parameter.

Never

Do not rebuild targets for referenced models. This setting requires the least processing time and, when available, uses Simulink cache files for faster simulations. To avoid rebuilds when developing a model, use this setting.

If model reference targets are out of date, the simulation may present invalid results. To have the software check for changes in known target dependencies and report if the model reference targets may be out of date, use the Never rebuild diagnostic parameter. To manually rebuild model reference targets, use the slbuild function.

For information on using and sharing Simulink cache files, see Share Simulink Cache Files for Faster Simulation.

Examples

Conditionally Rebuild Model Reference Targets

You can conditionally rebuild model reference targets by setting Rebuild to If changes detected or If changes in known dependencies detected.

Suppose you change a MATLAB^® script that executes as part of a callback script. The Model dependencies configuration parameter does not list the MATLAB script as a model dependency.

The Rebuild setting determines whether to rebuild the affected model reference targets.

• If changes detected causes a rebuild because the change affects the structural checksum of the model.

• If changes in known dependencies detected does not cause a rebuild because no known target dependency has changed.

This flow chart describes the processing Simulink performs when you set Rebuild to either If changes detected or If changes in known dependencies detected.

For the If changes detected or If changes in known dependencies detected settings, model reference targets rebuild when:

• A known target dependency has changed.

• A model file or library has changed and the structural checksum has changed.

• A potential target dependency trigger is detected and the structural checksum has changed.

• None of the above apply, the Rebuild setting is If changes detected, and the structural checksum has changed.

Tips

To improve rebuild detection speed and accuracy, use the Model dependencies configuration parameter to specify user-created dependencies.

Recommended Settings

Application	Setting
Debugging	No impact
Traceability	No impact
Efficiency	No impact
Safety precaution	If changes detected or Never When you use the Never setting, set the Never rebuild diagnostic configuration parameter to Error if rebuild required.

Programmatic Use

Parameter: UpdateModelReferenceTargets

Value1 : 'Force' | 'IfOutOfDateOrStructuralChange' | 'IfOutOfDate' | 'AssumeUpToDate'

Default: 'IfOutOfDateOrStructuralChange'

Limitations

The Rebuild configuration parameter does not apply to a Model block when both of these conditions apply:

• The block simulates in software-in-the-loop (SIL) or processor-in-the-loop (PIL) mode.

• The Code interface block parameter is set to Top model.

In this case, the code regeneration behavior for the referenced model is what you observe for a standalone model. For more information, see Control Regeneration of Top Model Code (Embedded Coder).

More About

Known Target Dependencies

Known target dependencies are files and data external to model files that Simulink examines for changes when checking if a model reference target is up to date. Simulink automatically computes a set of known target dependencies. Examples of known target dependencies are:

• Changes to the model workspace, if its data source is a MAT file or MATLAB (.m) file.

• Enumerated type definitions.

• User-written S-functions and their TLC files.

• Files specified in the Model dependencies configuration parameter.

• External files used by Stateflow^®, a MATLAB Function block, or a MATLAB System block.

• Dataflow subsystems – Analysis of dataflow subsystems requires that the simulation target rebuilds to profile and rebuilds again to partition the subsystem. In addition, the simulation target must rebuild if the machine running the simulation has fewer cores than the subsystem is partitioned to use, for example, if the simulation target was last built on a machine with a greater number of cores. For more information, see Simulation of Dataflow Domains (DSP System Toolbox).

Potential Target Dependencies

Potential target dependencies are files and data external to model files and model configuration settings that Simulink examines for changes when checking if a model reference target is up to date. Simulink automatically computes a set of potential target dependencies. Examples of potential target dependencies are:

• Changes to global variables

• Changes to targets of models referenced by this model

• The Signal resolution configuration parameter when set to either Explicit and implicit or Explicit and warn implicit

Simulink examines each potential target dependency to determine whether its state triggers a structural checksum check.

User-Created Dependencies

User-created dependencies are files that Simulink does not automatically identify, regardless of their potential impact on simulation results. Examples of user-created dependencies are:

• MATLAB files that contain code executed by callbacks

• MAT files that contain definitions for variables used by the model that are loaded as part of a customized initialization script

You can add user-created dependencies to the set of known target dependencies by using the Model dependencies parameter.

Structural Checksum

A structural checksum is a computation used to detect changes in the model that can affect simulation results. When Simulink computes the structural checksum, it loads and compiles the model. To compile the model, Simulink must execute callbacks and access all variables that the model uses. The structural checksum detects changes in user-created dependencies, regardless of whether you have specified those user-created dependencies in the Model dependencies configuration parameter.

For more information about the kinds of changes that affect the structural checksum, see Simulink.BlockDiagram.getChecksum.

Version History

Introduced before R2006a

R2019b: If changes detected ignores cosmetic changes

Starting in R2019b, If changes detected ignores cosmetic changes such as repositioning a block.