Model

Actual code generation support depends on block implementation.

HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic. For more information about using the Model block for HDL code generation and best practices and limitations, see Model Referencing for HDL Code Generation (HDL Coder).

See also Generate Black Box Interface for Referenced Model (HDL Coder) and Generate Parameterized Code for Referenced Models (HDL Coder).

Actual data type support depends on block implementation.

Loading a model that contains many instances of the same referenced model is faster in R2026a than in R2025b. The more times you reference the same model, the larger the performance improvement you experience.

For a simple example, suppose you create a model that references the vdp model many times. Open an example that uses the vdp model. Check that the vdp model is closed.

openExample("simulink_general/VanDerPolOscillatorExample")
close_system("vdp")

The following function creates a model that references the vdp model the number of times specified by num_instances. The function saves and closes the new model hierarchy and times how long it takes to load the top model.

function t = timingTest(num_instances)

% Create top model
topModel = "top";
new_system(topModel);
open_system(topModel);

% Add num_instances of vdp to top
refModel = "vdp";
for i = 1:num_instances
    add_block("simulink/Ports & Subsystems/Model", ...
        topModel+"/Model",MakeNameUnique="on", ...
        ModelName=refModel);
end

% Save and close top model
close_system(topModel,1);

% Measure performance of load_system function
tic;
load_system(topModel);
t = toc;

% Close and delete top model
close_system(topModel);
topFile = topModel+".slx";
delete(topFile);

end

Loading a model that contains 10 to 100 instances of a referenced model like vdp is about 1.9–2.8x faster than in the previous release.

This table provides the approximate execution times.

This evaluation was performed on a Windows^® 11, AMD EPYC™ 74F3 @ 3.19 GHz test system.

Saving a model hierarchy that contains many modified referenced models is faster in R2026a and R2025b than in R2025a. The more modified referenced models and levels of model hierarchy, the larger the performance improvements you experience.

The following function creates a vertical model reference hierarchy composed of the number of models specified by num_models. The function modifies each model in the hierarchy and times how long it takes to save the models. The function uses a temporary directory. After timing, the function closes the models and removes the temporary directory.

function t = timingTest(num_models)

% Navigate into temporary directory
currDir = pwd;
tempDir = tempname;
mkdir(tempDir)
cd(tempDir)

% Track created models
createdModels = cell(1,num_models);
topModel = "Model1";

% Create the hierarchy: Model1 -> Model2 -> ... -> ModelN
for i = num_models:-1:1
    mdl = sprintf("Model%d",i);
    createdModels{i} = mdl;
    new_system(mdl);
    open_system(mdl);
    if i < num_models
        refName = sprintf("Model%d", i+1);
        add_block("simulink/Ports & Subsystems/Model", ...
            mdl+"/Model",ModelName=refName);
    end
    save_system(mdl);
end

% Make all models in hierarchy dirty
cellfun(@(x) set_param(x,Description="Dirty"),createdModels);

% Measure performance of save_system function
tic;
save_system(topModel,SaveDirtyReferencedModels="on");
t = toc;

% Close created models
cellfun(@(x) close_system(x), createdModels);

% Remove temporary directory and created models
cd(currDir)
rmdir(tempDir,"s")

end

The performance improvement increases with the number of modified referenced models and levels of model hierarchy:

This table provides the approximate execution times.

This evaluation was performed on a Windows 11, AMD EPYC 74F3 @ 3.19 GHz test system.

When a parent solver takes a step that does not correspond to a communication step for a local solver, Model blocks that reference models configured to use a local solver provide an interpolated output value to the parent solver. You can configure Model blocks that produce real, double, continuous output signals to linearly interpolate these output values. Previously, only zero-order hold output signal handling was supported for variable-step local solvers and for fixed-step solvers that have a smaller step size than the parent solver.

To configure a model reference to linearly interpolate output values, set the Output signal handling parameter of the Model block to Linear. For parent solver time steps that do not correspond to communication steps, the Model block provides outputs by linearly interpolating the output value from the last communication step and the value the local solver computed for the next communication step.

When you set the Output signal handling parameter to Auto, the software selects the new linear output signal handling option in some cases. The table summarizes the output signal handling selection before R2026a and in R2026a.

You can initialize a simulation to a partial operating point by specifying the initial operating point of one or more Model blocks in the simulated model hierarchy. In previous releases, you could specify only a complete operating point for the top model, and the operating point of the top model initialized the entire model hierarchy.

You can configure multiple Model blocks in the same model hierarchy to save their final operating point or simulate from an initial operating point. By default, each Model block operating point is saved as a Simulink.op.ModelBlockOperatingPoint object in a property of the Simulink.SimulationOutput object returned by the simulation.

Saving and loading Model block operating points is not supported for Model blocks that:

Use the SynthesisAttributes HDL block property to specify the synthesis attributes for the block and its output signals. HDL Coder includes these attributes in the generated HDL code.

The DSPStyle HDL block property has been removed. To specify synthesis attributes for multiplier mapping, use the SynthesisAttributes HDL block property instead.

You can now configure a referenced model to use a variable-step local solver. Previously, only fixed-step local solvers were supported.

When you use a variable-step local solver, the Communication step size parameter of the Model block specifies when the parent and local solvers exchange data. Within the interval between hit times for the communication step size, the variable-step local solver determines the size of each local step based on the dynamics of the continuous states in the referenced model and the tolerance values you specify for the local solver.

When you use a variable-step local solver, only Zero-order hold input and output signal handling are supported.

For more information, see Use Local Solvers in Referenced Models.

Instance parameters are supported in all simulation modes for referenced models configured to use a local solver.

Model blocks that reference models configured to use local solvers now propagate a discrete sample time to the block output ports if the local solver uses zero-order hold output signal handling. The Communication step size parameter of the Model block defines the discrete sample time propagated to the block output ports. In previous releases, the Model block propagated the sample time of the port in the referenced model to the block output ports.

This change to sample time propagation:

In some cases, the change to sample time propagation causes warnings about sample time discrepancies or collisions. For example, when a Model block output port that now has a discrete sample time drives the input port of another model reference, the software issues a warning if the sample time of the input port in the referenced model does not match the sample time of the input signal in the top model. For more information, see Improve Simulation Performance Using Performance Advisor.

In most cases, this change does not affect numerical results and only results in fewer or different points in logged data for the Model block output signals. The table summarizes the impact of this change for different local solver configurations.

You can use local solvers for system components with faster dynamics by specifying a local step size that is smaller than the parent solver step size. The new Communication step size parameter specifies the discrete rate for communication between the parent and local solver. The communication step size is registered as a discrete rate in the parent model instead of the local solver step size.

The default value of the Output signal handling parameter is the new value Auto. When the Output signal handling parameter value is Auto, the software determines the method to use to interpolate continuous state or input signal values to the parent solver simulation time based on how the local step size compares to the communication step size. In previous releases, the local step size had to be greater than or equal to the parent solver step size, and the Auto option did not exist.

When the Input signal handling parameter value is Auto, the software now determines how to extrapolate continuous derivative or input signal values to the local simulation time based on the model structure and how the local step size compares to the communication step size. In previous releases, the software did not consider the model structure when selecting the interpolation method. Considering how the local step size compares to the communication step size was also not relevant because the Communication step size parameter did not exist.

You can configure a model that contains one or more blocks with wrapped states to use a local solver when referenced in a model hierarchy. Wrapping states can improve numerical stability for systems with cyclical state values and allows the state value to wrap to the start of the cycle without resetting the solver, which can slow simulation performance.

For example, you can model the angular position of a wheel as having a value that is always between 0 and 2π. When the wheel rotates beyond an angular position of 2π, the angular position wraps back to 0 rather than continually increasing.

Starting in R2023b, you can create ports on Model blocks without entering the referenced model the same way you can on a Subsystem block.

To create a port, pause on any of the four edges of the Model block. When your pointer turns into a cross, click. A new port appears on the edge you clicked, highlighted in blue. Pause your pointer on the new port. In the action menu that expands, select the type of port you want to create.

To delete an existing port, select the port and press Delete. To delete multiple ports, press Shift and select the ports. Then, press Delete.

For more information about creating Model block ports, see Add Ports to Model Reference Interface.

Model blocks at any location in a model hierarchy can use a local solver, including Model blocks inside referenced models that use local solvers.

Accelerator and rapid accelerator mode support simulating model reference hierarchies that use local solvers.

You can configure a referenced model to use a local solver when referenced by another model. The local solver solves the referenced model as a separate system of differential equations.

Using a local solver can facilitate system composition and integration. When you use local solvers, you can solve referenced models in system-level simulations using the same solver and step size used to design and test each model in isolation. Using local solvers can also reduce the amount of configuration adjustments you need to make to configuration parameters in referenced models while integrating the model into a larger system.

For some systems, using a local solver can improve simulation performance by allowing you to choose a solver that is more appropriate to solve the system in the referenced model or by reducing the number of redundant calculations in systems that have a wide range of dynamics among components.

These limitations apply for model hierarchies that reference one or more models configured to use a local solver:

For more information, see Use Local Solvers in Referenced Models.

Starting in R2019a, specifying variant models in Model blocks is no longer supported. The Model Variants block, which was a Model block preconfigured to specify variant models, is also no longer supported. Loading a model that contains these blocks converts them to Variant Subsystem blocks that contain Model blocks that represent the variant choices.

Variant Subsystem blocks provide these advantages:

The Variant Subsystem block parameter Analyze all choices during update diagram and generate preprocessor conditionals behaves differently from the Model block parameter Generate preprocessor conditionals. Instead of causing simulation and update diagram to compile the active variant only, the Variant Subsystem block parameter compiles all variants.

If you have scripts that use Model block parameters for variants, you must update them to use Variant Subsystem block parameters.