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 Code 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 include:

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 Auto.
An extern declaration 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 Default in the Code Mapping editor, symbols for Model default parameters are generated by using unstructured variables (rtP_xxx) instead of being written into the model_P 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 Configure Instance-Specific Values for Block Parameters in a Referenced Model.

Storage Classes for Signals in Model Blocks

Models containing Model blocks can use signals of storage class Auto.

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 Unstructured.

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:

An extern declaration 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 extern declarations 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.

Note

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
`Auto`	`Non-Auto`	Function argument	Signal label mismatch
`Model default` (when the Code Mapping editor specifies `Default` storage class) or resolved to Signal Object	`Non-Auto`	Function argument	Signal label mismatch
`Non-Auto`	`Auto`	Global variable	None
`Non-Auto`	`Non-Auto`	Global variable	One of the storage classes must be `Auto` (otherwise there is an error)

These 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 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 Non-Auto or resolves to a Simulink.Signal object 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 Auto.
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 error, warning, or none.