| Simulink® | |
| On this page… |
|---|
Limitations on All Model Referencing |
The following Simulink® limitations apply to model referencing. In addition, a model reference hierarchy must satisfy all of the requirements listed in Simulink® Model Referencing Requirements.
In the following two cases, Simulink does not propagate 0-based or 1-based indexing information to referenced-model root-level ports connected to blocks that accept indexes, like the Assignment block, or produce indexes, like the For Iterator block.
If a root-level input port of the referenced model is connected to index inputs in the model that have different 0-based or 1-based indexing settings, Simulink does not set the 0-based or 1-based indexing property of the root-level Inport.
If a root-level output port of the referenced model is connected to index outputs in the model that have different 0-based or 1-based indexing settings, Simulink does not set the 0-based or 1-based indexing property of the root-level Outport.
In these cases, the lack of propagation can cause Simulink to fail to detect incompatible index connections.
If a referenced model has any of the following properties, the model must specify Configuration Parameters > Model Referencing > Total number of instances allowed per top model as One. No other instances of the model can exist in the hierarchy. If the parameter is not set correctly, or more than one instance of the model exists in the hierarchy, an error occurs. The properties are:
The model references another model which has been set to single instance
The model contains a state or signal with non-auto storage class
The model uses any of the following Stateflow® constructs:
Machine-parented data
Machine-parented events
Stateflow graphical functions
Working with the Simulink Debugger in a parent model, you can set breakpoints at Model block boundaries, allowing you to look at the block's input and output values, but you cannot set a breakpoint inside the submodel that the Model block references. See Simulink® Debugger for more information.
The Model Coverage tool, which is part of Simulink Verification and Validation, works for at most one referenced model at a time. That model must execute in Normal mode. See Using Model Coverage for more information.
Simulink Design Verifier does not work with model referencing.
A model that contains a Stateflow chart cannot be referenced multiple times in the same model reference hierarchy if:
The Stateflow chart contains exported graphical functions.
The Stateflow model contains machine-parented data or events.
Referenced models cannot use asynchronous rates internally. However, a function-call model referenced in a top model can be triggered by an asynchronous source within the top model. See Defining Function-Call Models for more information.
Mask callbacks cannot add Model blocks or change existing Model block parameter values. Violating this requirement generates an error. See Creating Block Masks for more information.
A referenced model can input or output only those user-defined data types that are fixed-point or defined by Simulink.DataType or Simulink.Bus objects.
Model blocks referencing models that contain assignment blocks that are not in an iterator subsystem cannot be placed in an iterator subsystem.
If you want to initialize the states of a model that references other models with states, you must specify the initial states in structure format.
The Model Browser does not display Model blocks in its tree view. Use the Model Explorer to browse a referenced model hierarchy.
A referenced model cannot directly access the signals in a multi-rate bus. Connecting Multi-Rate Buses to Referenced Models describes a technique for overcoming this limitation.
A continuous sample time cannot be propagated to a Model block that is sample-time independent.
You cannot log the output of a Ground block in a referenced model even if you testpoint it.
Goto/From blocks cannot cross model reference boundaries.
You cannot print a referenced model from a top model.
Enabling the Simulink Profiler on a parent model does not enable profiling for referenced models. Profiling must be enabled separately for each submodel. See Capturing Performance Data.
Model coverage cannot be specified for any referenced model if coverage is specified for the top model. Coverage can be specified for at most one referenced model at a time. That model must execute in Normal mode. See Using Model Coverage.
When the same submodel appears more than once in a hierarchy, at most one of these instances can specify Normal mode. All the rest must specify Accelerator mode.
Accelerator mode simulation ignores custom code settings in the Configuration Parameter dialog box and custom code blocks when generating the simulation target for a referenced model.
Some restrictions exist on grouped custom storage classes in referenced models. See Custom Storage Class Limitations for details.
Data type replacement is not supported for simulation target code generation for referenced models.
Simulation targets do not include Stateflow target custom code.
To Workspace blocks, Scope blocks, and all types of runtime display, such as the display of port values and signal values, have no effect when specified in referenced models executing in Accelerator mode. The result during simulation is the same as if the constructs did not exist.
Referenced models executing in Accelerator mode cannot log data to MAT-files. If data logging is enabled for a referenced model, Simulink disables the option before code generation and re-enables it afterwards.
If a referenced model has any of the following properties, and the model executes in Accelerator mode, the model must specify Configuration Parameters > Model Referencing > Total number of instances allowed per top model as One. No other instances of the model can exist in the hierarchy, in either Normal mode or Accelerator mode. If the parameter is not set correctly, or more than one instance of the model exists in the hierarchy, an error occurs. The properties are:
The model contains a subsystem that is marked as function
The model contains an S-function that is:
Inlined but has not set the option SS_OPTION_WORKS_WITH_CODE_REUSE
Not inlined
The model contains a function-call subsystem that:
Has been forced by Simulink to be a function
Is called by a wide signal
If a referenced model contains an S-function that should be inlined using a Target Language Compiler file, the S-function must use the ssSetOptions macro to set the SS_OPTION_USE_TLC_WITH_ACCELERATOR option in its mdlInitializeSizes method. The simulation target will not inline the S-function unless this flag is set.
The Real-Time Workshop® S-function target does not support model referencing.
A referenced model cannot use noninlined S-functions in the following cases:
The model uses a variable-step solver.
The S-function was generated by Real-Time Workshop.
The S-function supports use of fixed-point numbers as inputs, outputs, or parameters.
The model is referenced more than once in the model reference hierarchy. To work around this limitation, make copies of the referenced model, assign different names to the copies, and reference a different copy at each location that needs the model.
Simulink tools that require access to a model's internal data or configuration (including Model Coverage, the Report Generator, the Simulink Debugger, and the Simulink Profiler) have no effect on referenced models executing in Accelerator mode. Specifications made and actions taken by such tools are ignored and effectively do not exist.
If a subsystem contains Model blocks, you cannot build a subsystem module by right-clicking the subsystem or by using Tools > Real-Time Workshop > Build subsystem.
If you generate code for an atomic subsystem as a reusable function, inputs or outputs that connect the subsystem to a referenced model can affect code reuse, as described in Reusable Code and Referenced Models.
Real-Time Workshop grt_malloc targets do not support model reference.
The Real-Time Workshop S-function target does not support model referencing.
Errors or unexpected behavior can occur if a Model block is part of a cycle, the Model block is a direct feedthrough block, and an algebraic loop results. See Model Blocks and Direct Feedthrough for details.
The External mode option is not supported. If it is enabled, it is ignored by Accelerator mode.
| Defining Function-Call Models | Working with Blocks | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |