Main Content

Code Generation Limitations for Model Reference

Code generation limitations for model references influence how you properly set up the model reference hierarchy for code generation.

In addition to these limitations, a model reference hierarchy used for code generation must satisfy:

Storage Class Limitations

If you have Embedded Coder®, some restrictions exist on grouped storage classes in referenced models. For details, see Storage Class Limitations.

Data Logging Limitations

  • To Workspace blocks and Scope blocks are ignored when Simulink Coder generates code for a referenced model. The resulting code is the same as if the blocks did not exist. In some cases for models with Scope block and MAT-file logging enabled, the code generator produces an extra PWork in the model's DWork structure.

  • Code generated for referenced models cannot log data to MAT-files. If you enable data logging for a referenced model, Simulink Coder disables the option before code generation and re-enables it afterward.

  • If you log states for a model that contains referenced models, the ordering of the states in the output is determined by block sorted order, and might not match between simulation output and generated code MAT-file logging output.

State Initialization Limitations

When a top model uses the model configuration parameter Initial state to specify initial conditions, Simulink Coder does not initialize the discrete states of the referenced models during code generation.

Model Reuse Limitations

If a referenced model used for code generation has at least one of the following characteristics, the model must specify the model configuration parameter Total number of instances allowed per top model as One. Other instances of the model can exist in the hierarchy. If you do not set the parameter to One, or more than one instance of the model exists in the hierarchy, an error occurs. The characteristics are:

  • The model references another model that has been set to a single instance.

  • The model contains an internal signal or state that has a storage class that is not supported for multi-instance models. You must set the storage class to Auto or Model default for internal signals and states. The default storage class for internal data must be a multi-instance storage class.

  • The model uses exported Stateflow® graphical functions.

  • The model contains an S-function that is:

    • Inlined but you have not set the option SS_OPTION_WORKS_WITH_CODE_REUSE

    • Not inlined

  • The model contains a function-call subsystem that:

    • The Simulink engine forces to be a function

    • Is called by a wide signal

S-Functions Limitations

  • A referenced model cannot use noninlined S-functions generated by Simulink Coder.

  • The Simulink Coder S-function target does not support model referencing.

For additional information, see S-Functions in Referenced Models.

Subsystems Limitations

If you generate code for an atomic subsystem as a reusable function, inputs or outputs that connect the subsystem to a referenced model might prevent code reuse, as described in Generate Reentrant Code from Subsystems.

Targets Limitation

The Simulink Coder S-function target does not support model referencing.

Conditional Models Limitation

When a model contains a trigger or enable port, you cannot generate standalone Simulink Coder code.

Local Solver Limitation

You can not generate code for a model that uses a local solver. For more information on local solvers, see Use Local Solvers in Referenced Models.

Related Topics