Storage Classes for Parameters and Signals Used in Model Blocks
To transfer data between your referenced model and top model, use signals and parameters. You can also use parameters to integrate external data into the model reference hierarchy. To include one model inside another model and create a model reference hierarchy, use a Model block.
You can apply a storage class to a data item in a model, such as signal or parameter, to:
Make the data item appear in the generated code as a global symbol, typically a global variable.
Prevent optimizations such as Default parameter behavior and Signal storage reuse from eliminating the data item from the generated code.
For examples, see C Data Code Interface Configuration for Model Interface Elements.
You can map a storage class to a category of model data elements or to an individual
element by using the Code Mappings editor or the Code Mappings API (
coder.mapping.api.CodeMapping). You can specify code configurations
settings specific to that storage class, such as header files, definition files, and
memory sections using the Code Mappings editor or the API. For more information, see
Mappings Editor – C.
Storage Classes for Parameters in Model Blocks
Models containing Model blocks can use storage classes for parameters to interface
with external code. Storage classes, with the exception of
Auto, are tunable. The supported storage classes
Predefined storage classes in Simulink® Coder™ and Embedded Coder®
A new storage class created by using the Embedded Coder Dictionary
For limitations on Embedded Coder storage classes, see Storage Class Limitations.
The restrictions on parameters in referenced models are:
Tunable parameters are not supported for noninlined S-functions.
Tunable parameters set through the Model Parameter Configuration dialog box are ignored.
Concerning how global tunable parameters are declared, defined, and used in code generated for targets. consider:
A global tunable parameter is a parameter in the base workspace that has a storage class other than
externdeclaration is generated for models that use a given parameter.
If a parameter is exported, the top model defines (allocates memory for) the parameter whether the top model 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
Defaultin the Code Mapping editor, symbols for
Model defaultparameters are generated by using unstructured variables (
rtP_xxx) instead of being written into the
structure. You can then compile each referenced model independently.
Parameters that you use as Model block arguments must be defined in the referenced model workspace. For details, see Parameterize Instances of a Reusable Referenced Model.
Storage Classes for Signals in Model Blocks
Models containing Model blocks can use signals of storage class
A global signal is a signal that has a storage class other than
Auto. The supported storage classes include:
Predefined storage classes in Simulink Coder and Embedded Coder
A new storage class created by using Embedded Coder Dictionary
If you have Embedded Coder, you can create a global signal by using a storage class defined in
the Embedded Coder Dictionary that has Storage Type set as
Unstructured or by creating a storage in the Embedded
Coder Dictionary that has Storage Type set as
These signals are distinct from individual 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, these signals are treated as test points that have the
Auto storage class.
When you declare signals as global, be aware of how the signal data is handled. Global signals are declared, defined, and used as follows:
externdeclaration is generated for models that use a global signal.
As a result, if a signal crosses a Model block boundary, the top model and the referenced model both generate
externdeclarations for the signal.
For an exported signal, the top model defines (allocates 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.
Storage classes that you create by using the Embedded Coder Dictionary also follow the preceding rules for the top model.
In a referenced model, you cannot use the storage class that you create by using the Embedded Coder Dictionary on root-level Inports and Outports.
Certain storage classes have limited support for use with model reference. See Storage Class Limitations.
Signal Name Mismatches Across Model Reference Boundary
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 the
Auto storage class. When such signals are
test pointed or are global, certain restrictions apply. This table describes how
mismatches in signal labels and storage classes between parent and referenced models
are handled by the software.
Relationships of Signals and Storage Classes Across Model Reference Boundary
|Storage Class in Referenced Model||Storage Class in Parent Model||Signal Passing Method||Signal Mismatch Checking|
|Function argument||Signal label mismatch|
|Function argument||Signal label mismatch|
|Global variable||One of the storage classes must be
These signal resolution rules apply to code generation:
If the storage class of a root input or output signal in a referenced model is
Model default(when you set the storage class of the corresponding data category to
Defaultin the Code Mapping editor), the signal is passed as a function argument. When such a signal is
Non-Autoor resolves to a
Simulink.Signalobject in the parent model, the Signal label mismatch diagnostic is applied.
If a root input or output signal in a referenced model is global, the signal is communicated by using direct memory access (global variable). The corresponding signal in the parent model must be
You cannot use a storage class that you create by using the Embedded Coder Dictionary in a referenced model.
You can set the model configuration parameter Signal label
mismatch diagnostic to