Models containing Model blocks can use signals
of storage class Auto without restriction.
However, when you declare signals to be global, you must be aware
of how the signal data will be handled.
A global signal is a signal with a storage class other than Auto:
ExportedGlobal
ImportedExtern
ImportedExternPointer
Custom
The above are distinct from signals that use the storage class Model
default when you set the default storage class of the corresponding data
category to Default in the Code Mapping Editor, which are treated as
test points with Auto storage class.
Global signals are declared, defined, and used as follows:
An extern declaration is generated for models that use a
given global signal.
As a result, if a signal crosses a Model block boundary, the
top model and the referenced model both generate extern
declarations for the signal.
For an exported signal, the top model is responsible for defining (allocating memory for) the signal, whether or not the top model itself uses the signal.
Global signals used by a referenced model are accessed directly (as global memory). They are not passed as arguments to the functions that are generated for the referenced models.
Custom storage classes also follow the above rules. However, certain storage classes are not currently supported for use with model reference. For details, see Storage Class Limitations.
Storage classes are supported for simulation and code generation. Storage classes, with the
exception of Auto, are tunable. The supported storage
classes thus include
Model default
ExportedGlobal
ImportedExtern
ImportedExternPointer
Custom
Note the following restrictions on parameters in referenced models:
Tunable parameters are not supported for noninlined S-functions.
Tunable parameters set using the Model Parameter Configuration dialog box are ignored.
Note the following considerations concerning how global tunable parameters are declared, defined, and used in code generated for targets:
A global tunable parameter is a parameter in the base
workspace with a storage class other than Auto.
An extern declaration is generated by for models that
use a given parameter.
If a parameter is exported, the top model is responsible for defining (allocating memory for) the parameter (whether it uses the parameter or not).
Global parameters are accessed directly (as global memory). They are not passed as arguments to the functions that are generated for the referenced models.
In a referenced model that sets the default storage class for a category of parameter data to
Default in the Code Mapping Editor, symbols for
Model default parameters are generated using
unstructured variables (rtP_xxx) instead of being written
into the model_P
Certain storage classes for parameters are not currently supported for model reference. For details, see Storage Class Limitations.
Parameters used as Model block arguments must be defined in the referenced model's workspace. For details, see Parameterize Instances of a Reusable Referenced Model (Simulink).
Within a parent model, the name and storage class for a signal entering or leaving a Model block might not match those of the signal attached to the root inport or outport within that referenced model. Because referenced models are compiled independently without regard to a parent model, they cannot adapt to the possible variations in how parent models label and store signals.
The code generator accepts cases where input and output signals in a referenced model have
Auto storage class. When such signals are test
pointed or are global, as described above, certain restrictions apply. The following
table describes how mismatches in signal labels and storage classes between parent
and referenced models are handled:
Relationships of Signals and Storage Classes Across Model Reference Boundary
Referenced Model | Parent Model | Signal Passing Method | Signal Mismatch Checking |
|---|---|---|---|
| Any storage class | Function argument | None |
| Any storage class | Function argument | Signal label mismatch |
| Auto or | Global variable | Signal label mismatch |
|
| Global variable | Labels and storage classes must be identical (else error) |
To summarize, the following signal resolution rules apply to code generation:
If the storage class of a root input or output signal in a referenced model is
Auto (or is Model default
when you set the storage class of the corresponding data category to
Default in the Code Mapping Editor), the signal is
passed as a function argument.
When such a signal is Model default or resolves to a
Simulink.Signal object, the Signal
label mismatch diagnostic is applied.
If a root input or output signal in a referenced model is global, it is communicated by using direct memory access (global variable). In addition,
If the corresponding signal in the parent model is also global, the names and storage classes must match exactly.
If the corresponding signal in the parent model is not global, the Signal label mismatch diagnostic is applied.
You can set the Signal label mismatch diagnostic
to error, warning,
or none in the Diagnostics >
Connectivity pane of the Configuration Parameters dialog
box.