Subsystem, Atomic Subsystem, CodeReuse Subsystem

Library:
Simulink / Ports & Subsystems

Ports

Input

`In` — Signal input to a subsystem
scalar | vector | matrix

Placing an Inport block in a subsystem adds an external input port to the Subsystem block. The port label matches the name of the Inport block.

Use Inport blocks to get signals from the local environment.

Output

expand all

`Out` — Signal output from a subsystem
scalar | vector | matrix

Placing an Outport block in a subsystem adds an output port from the Subsystem block. The port label on the Subsystem block is the name of the Outport block.

Use Outport blocks to send signals to the local environment.

Parameters

expand all

Parameters on the Code Generation tab require a Simulink Coder™ or Embedded Coder^® license.

Main

`Show port labels` — Display options for port labels
`FromPortIcon` (default) | `FromPortBlockName` | `SignalName`

Select how to display port labels on the Subsystem block icon.

none: Do not display port labels.
FromPortIcon: If the corresponding port icon displays a signal name, display the signal name on the Subsystem block. Otherwise, display the port block name.
FromPortBlockName: Display the name of the corresponding port block on the Subsystem block.
SignalName: If a signal name exists, display the name of the signal connected to the port on the Subsystem block. Otherwise, display the name of the corresponding port block.

Programmatic Use

Parameter: ShowPortLabels

Type: character vector

Value: 'FromPortIcon' | 'FromPortBlockName' | 'SignalName'

Default: 'FromPortIcon'

`Read/Write permissions` — Levels of access to contents of subsystem
`ReadWrite` (default) | `ReadOnly` | `NoReadOrWrite`

Control user access to the contents of the subsystem.

ReadWrite: Enable opening and modification of subsystem contents.
ReadOnly: Enable opening but not modification of the subsystem. If the subsystem resides in a block library, you can create and open links to the subsystem and can make and modify local copies of the subsystem but cannot change the permissions or modify the contents of the original library instance.
NoReadOrWrite: Disable opening or modification of subsystem. If the subsystem resides in a library, you can create links to the subsystem in a model but cannot open, modify, change permissions, or create local copies of the subsystem.

Note

You do not receive a response if you attempt to view the contents of a subsystem whose Read/Write permissions parameter is set to NoReadOrWrite. For example, when double-clicking such a subsystem, Simulink does not open the subsystem and does not display any messages.

Programmatic Use

Parameter: Permissions

Type: character vector

Value: 'ReadWrite' | 'ReadOnly' | 'NoReadOrWrite'

Default: 'ReadWrite'

`Name of error callback function` — Name of function to be called if error occurs
`''` (default) | function name

Enter name of a function to be called if an error occurs while Simulink is executing the subsystem.

Simulink passes two arguments to the function: the handle of the subsystem and a character vector that specifies the error type. If no function is specified, Simulink displays a generic error message if executing the subsystem causes an error.

Programmatic Use

Parameter:


                                        ErrorFcn

Type: character vector

Value: '' |

'<function
                                        name>'

Default: ''

`Permit hierarchical resolution` — Resolution for workspace variable names
`All` (default) | `ExplicitOnly` | `None`

Select whether to resolve names of workspace variables referenced by this subsystem.

For more information, see Symbol Resolution and Symbol Resolution Process.

All: Resolve all names of workspace variables used by this subsystem, including those used to specify block parameter values and Simulink data objects (for example, Simulink.Signal objects).
ExplicitOnly: Resolve only names of workspace variables used to specify block parameter values, data store memory (where no block exists), signals, and states marked as “must resolve”.
None: Do not resolve any workspace variable names.

Programmatic Use

Parameter: PermitHierarchicalResolution

Type: character vector

Value: 'All' | 'ExplicitOnly' | 'None'

Default: 'All'

`Treat as atomic unit` — Option to execute subsystem as one unit
off (default) | on

Causes Simulink to treat the subsystem as a unit when determining the execution order of block methods.

off: Treat all blocks in the subsystem as being at the same level in the model hierarchy as the subsystem when determining block method execution order. This can cause execution of methods of blocks in the subsystem to be interleaved with execution of methods of blocks outside the subsystem.
on: Treat the subsystem as a unit when determining the execution order of block methods. For example, when it needs to compute the output of the subsystem, Simulink invokes the output methods of all the blocks in the subsystem before invoking the output methods of other blocks at the same level as the Subsystem block.

Programmatic Use

Parameter: TreatAsAtomicUnit

Type: character vector

Value: 'off' | 'on'

Default: 'off'

`Minimize algebraic loop occurrences` — Option to eliminate artificial algebraic loops
off (default) | on

Try to eliminate any artificial algebraic loops that include the atomic subsystem

off: Do not try to eliminate any artificial algebraic loops that include the atomic subsystem.
on: Try to eliminate any artificial algebraic loops that include the atomic subsystem.

Dependencies

To enable this parameter, select the Treat as atomic unit parameter.

Programmatic Use

Parameter: MinAlgLoopOccurrences

Type: character vector

Value: 'off' | 'on'

Default: 'off'

`Schedule As` — Type of scheduling
`Sample Time` (default) | `Periodic Partition` | `Aperiodic Partition`

Specify how to schedule the subsystem.

Sample time: Specify whether all blocks in this subsystem must run at the same rate or can run at different rates.
Periodic Partition: Schedule the subsystem as a periodic partition. Specify a partition name and a sample time corresponding to the rate at which the partition runs.
Aperiodic Partition: Schedule the subsystem as an aperiodic partition. Specify a partition name.

Dependencies

To enable this parameter, select the Treat as atomic unit parameter.

Programmatic Use

Parameter: ScheduleAs

Type: character vector

Value: 'SampleTime' | 'DiscretePartition' | 'UnconstrainedPartition'

Default: 'SampleTime'

`Partition Name` — Name of partition
character vector

Specify name of the partition for the subsystem.

Dependencies

To enable this parameter, select the Treat as atomic unit parameter, and set Schedule As to Periodic Partition or Aperiodic Partition.

Programmatic Use

Parameter: PartitionName

Type: character vector

Value: ''

Default: ''

`Sample time` — Time interval
`-1` (default) | `[Ts 0]`

Specify whether all blocks in this subsystem must run at the same rate or can run at different rates.

If the blocks in the subsystem can run at different rates, specify the subsystem sample time as inherited (-1).
If all blocks must run at the same rate, specify the sample time corresponding to this rate as the value of the Sample time parameter.
If any of the blocks in the subsystem specify a different sample time (other than -1 or inf), Simulink displays an error message when you update or simulate the model. For example, suppose all the blocks in the subsystem must run 5 times a second. To ensure this, specify the sample time of the subsystem as 0.2. In this example, if any of the blocks in the subsystem specify a sample time other than 0.2, -1, or inf, Simulink displays an error when you update or simulate the model.

-1: Specify inherited sample time. Use this sample time if the blocks in the subsystem can run at different rates.
[Ts 0]: Specify periodic sample time.

Dependencies

To enable this parameter, select the Treat as atomic unit parameter.

Programmatic Use

Parameter: SystemSampleTime

Type: character vector

Value: '-1' | '[Ts 0]'

Default: '-1'

`Variant control` — Variant control (condition) expression
`Variant` (default) | logical expression

Specify variant control (condition) expression that executes a variant Simulink Function block when the expression evaluates to true.

For more information, see Simulink.Variant.

Variant

Default name for a logical (Boolean) expression.

logical expression

A logical (Boolean) expression or a Simulink.Variant object representing a logical expression.

The function is activated when the expression evaluates to true.

If you want to generate code for your model, define the variables in the expression as Simulink.Parameter objects.

Dependencies

Enable this parameter by adding a Subsystem block inside a Variant Subsystem block.

Programmatic Use

Block parameter: VariantControl

Type: character vector

Value: 'Variant' |

'<logical
                                        expression>'

Default: 'Variant'

`Treat as grouped when propagating variant conditions` — Option to treat subsystem as unit when propagating variant conditions
`on` (default) | `off`

Causes Simulink to treat the subsystem as a unit when propagating variant conditions from Variant Source blocks or to Variant Sink blocks.

on: Simulink treats the subsystem as a unit when propagating variant conditions from Variant Source blocks or to Variant Sink blocks. For example, when Simulink computes the variant condition of the subsystem, it propagates that condition to all the blocks in the subsystem.
off: Simulink treats all blocks in the subsystem as being at the same level in the model hierarchy as the subsystem itself when determining their variant condition.

Programmatic Use

Parameter: TreatAsGroupedWhenPropagatingVariantConditions

Type: character vector

Value: 'on' | 'off'

Default: 'on'

Code Generation

`Function packaging` — Code format
`Auto` (default) | `Inline` | `Nonreusable function` | `Reusable function`

Select the code format to be generated for an atomic (nonvirtual) subsystem.

Auto

Simulink Coder and Embedded Coder choose the optimal format for you based on the type and number of instances of the subsystem that exist in the model.

Inline

Simulink Coder and Embedded Coder inline the subsystem unconditionally.

Nonreusable function

If Filename options is set to Auto, Simulink Coder and Embedded Coder package separate functions in the model file. If File name options is set to Use subsystem name, Use function name, or User specified using different file names, Simulink Coder and Embedded Coder package separate functions in separate files.

Subsystems with this setting generate functions that might have arguments depending on the Function interface parameter setting. You can name the generated function and file using parameters Function name and File name (no extension). These functions are not reentrant.

Reusable function

Simulink Coder and Embedded Coder generate a function with arguments that allows reuse of subsystem code when a model includes multiple instances of the subsystem.

This option also generates a function with arguments that allows subsystem code to be reused in the generated code of a model reference hierarchy that includes multiple instances of a subsystem across referenced models. In this case, the subsystem must be in a library.

For more information, see:

Control Generation of Functions for Subsystems (Simulink Coder)
Generate Code and Executables for Individual Subsystems (Simulink Coder)
Inline Subsystem Code (Simulink Coder)
Generate Subsystem Code as Separate Function and Files (Simulink Coder)
Generate Reusable Code from Library Subsystems Shared Across Models (Simulink Coder)

Tips

When you want multiple instances of a subsystem to be represented as one reusable function, you can designate each one of them as Auto or as Reusable function. It is best to use one or the other, as using both creates two reusable functions, one for each designation. The outcomes of these choices differ only when reuse is not possible. Selecting Auto does not allow control of the function or file name for the subsystem code.
The Reusable function and Auto options both try to determine if multiple instances of a subsystem exist and if the code can be reused. The difference between the options' behavior is that when reuse is not possible:
- Auto yields inlined code, or if circumstances prohibit inlining, separate functions for each subsystem instance.
- Reusable function yields a separate function with arguments for each subsystem instance in the model.
If you select Reusable function while your generated code is under source control, set File name options to Use subsystem name, Use function name, or User specified. Otherwise, the names of your code files change whenever you modify your model, which prevents source control on your files.

Dependencies

This parameter requires Simulink Coder for code generation.
To enable this parameter, select Treat as atomic unit.

Programmatic Use

Parameter: RTWSystemCode

Type: character vector

Value: 'Auto' | 'Inline' | 'Nonreusable function' | 'Reusable function'

Default: 'Auto'

`Function name options` — How to name generated function
`Auto` (default) | `Use subsystem name` | `User specified`

Select how Simulink Coder names the function it generates for the subsystem.

If you have an Embedded Coder license, you can control function names with options on the Configuration Parameter Code Generation > Identifiers pane.

Auto

Assign a unique function name using the default naming convention, model_subsystem(), where model is the name of the model and subsystem is the name of the subsystem (or that of an identical one when code is being reused).

If you select Reusable function for the Function packaging parameter and there are multiple instances of the reusable subsystem in a model reference hierarchy, in order to generate reusable code for the subsystem, Function name options must be set to Auto.

Use subsystem name

Use the subsystem name as the function name. By default, the function name uses the naming convention model_subsystem.

Note

When a subsystem is in a library block and the subsystem parameter Function packaging is set to Reusable function, if you set the Use subsystem name option, the code generator uses the name of the library block for the subsystem function name and file name.

User specified

Enable the Function name field. Enter any legal C or C++ function name, which must be unique.

For more information, see Control Generation of Functions for Subsystems (Simulink Coder).

Dependencies

This parameter requires a Simulink Coder license.
To enable this parameter, set Function packaging to Nonreusable function or Reusable function.

Programmatic Use

Parameter: RTWFcnNameOpts

Type: character vector

Value: 'Auto' |

'Use subsystem
                                        name'

|

'User
                                    specified'

Default: 'Auto'

`Function name` — Name of function for subsystem code
`''` (default) | function name

Specify a unique, valid C or C++ function name for subsystem code.

Use this parameter if you want to give the function a specific name instead of allowing the Simulink Coder code generator to assign its own autogenerated name or use the subsystem name. For more information, see Control Generation of Functions for Subsystems (Simulink Coder).

Dependencies

This parameter requires a Simulink Coder license.
To enable this parameter, set the Function name options parameter to User specified.

Programmatic Use

Parameter: RTWFcnName

Type: character vector

Value: '' |

'<function
                                        name>'

Default: ''

`File name options` — How to name generated file
`Auto` (default) | `Use subsystem name` | `Use function name` | `User specified`

Select how Simulink Coder names the separate file for the function it generates for the subsystem.

Auto

Depending on the configuration of the subsystem and how many instances are in the model, Auto yields different results:

If the code generator does not generate a separate file for the subsystem, the subsystem code is generated within the code module generated from the subsystem parent system. If the subsystem parent is the model itself, the subsystem code is generated within model.c or model.cpp.
If you select Reusable function for the Function packaging parameter and your generated code is under source control, consider specifying a File name options value other than Auto. This prevents the generated file name from changing due to unrelated model modifications, which is problematic for using source control to manage configurations.
If you select Reusable function for the Function packaging parameter and there are multiple instances of the reusable subsystem in a model reference hierarchy, in order to generate reusable code for the subsystem, File name options must be set to Auto.

Use subsystem name

The code generator generates a separate file, using the subsystem (or library block) name as the file name.

Note

When File name options is set to Use subsystem name, the subsystem file name is mangled if the model contains Model blocks, or if a model reference target is being generated for the model. In these situations, the file name for the subsystem consists of the subsystem name prefixed by the model name.

Use function name

The code generator uses the function name specified by Function name options as the file name.

User specified

This option enables the File name (no extension) text entry field. The code generator uses the name you enter as the file name. Enter any file name, but do not include the .c or .cpp (or any other) extension. This file name need not be unique.

Note

While a subsystem source file name need not be unique, you must avoid giving nonunique names that result in cyclic dependencies (for example, sys_a.h includes sys_b.h, sys_b.h includes sys_c.h, and sys_c.h includes sys_a.h).

Dependencies

This parameter requires a Simulink Coder license.
To enable this parameter, set Function packaging to Nonreusable function or Reusable function.

Programmatic Use

Parameter: RTWFileNameOpts

Type: character vector

Value: 'Auto' |

'Use subsystem
                                        name'

| 'Use function name' | 'User specified'

Default: 'Auto'

`File name (no extension)` — Name of generated file
`''` (default) | file name

The file name that you specify does not have to be unique. However, avoid giving non-unique names that result in cyclic dependencies (for example, sys_a.h includes sys_b.h, sys_b.h includes sys_c.h, and sys_c.h includes sys_a.h).

For more information, see Control Generation of Functions for Subsystems (Simulink Coder).

Dependencies

This parameter requires a Simulink Coder license.
To enable this parameter, set File name options to User specified.

Programmatic Use

Parameter: RTWFileName

Type: character vector

Value: '' |

'<file
                                    name>'

Default: ''

`Function interface` — Select to use arguments with generate function
`void_void` (default) | `Allow arguments (Optimized)` | `Allow arguments (Match graphical interface)`

Select to use arguments with generated function.

void_void

Generate a function without arguments and pass data as global variables. For example:

void subsystem_function(void)

Allow arguments (Optimized)

Generate a function that uses arguments instead of passing data as global variables. This specification reduces global RAM. It might reduce code size and improve execution speed and enable the code generator to apply additional optimizations. For example:

void subsystem_function(real_T rtu_In1, real_T rtu_In2, 
                        real_T *rty_Out1)

In some cases, when generating optimized code, the code generator might not generate a function that has arguments.

Allow arguments (Match graphical interface)

Generate a function interface that uses arguments that match the Subsystem graphical block interface. The generated function interface is predictable and does not change. A predictable interface can be useful for debugging and testing your code and integrating with external applications. For example, if a model has two Inports and two Outports, then the generated function interface is:

void subsystem_function(real_T rtu_In1, real_T rtu_In2, 
                        real_T *rty_Out1, real_T *rty_Out2)

For more information, see:

Reduce Global Variables in Nonreusable Subsystem Functions (Embedded Coder)
Generate Predictable Function Interface to Match Graphical Block Interface (Embedded Coder)
Generate Modular Function Code for Nonvirtual Subsystems (Embedded Coder)

Dependencies

This parameter requires Embedded Coder and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function.

Programmatic Use

Parameter: FunctionInterfaceSpec

Type: character vector

Value: 'void_void' |

'Allow arguments
                                        (Optimized)'

|

'Allow arguments (Match
                                        graphical interface)'

Default: 'void_void'

`Function with separate data` — Control code generation for subsystem
off (default) | on

Generate subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem.

off: Do not generate subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem.
on: Generate subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem. The subsystem data structure is declared independently from the parent model data structures. A subsystem with separate data has its own block I/O and DWork data structure. As a result, the generated code for the subsystem is easier to trace and test. The data separation also tends to reduce the maximum size of global data structures throughout the model, because they are split into multiple data structures.

For details on how to generate modular function code for an atomic subsystem, see Generate Modular Function Code for Nonvirtual Subsystems (Embedded Coder).

For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).

Dependencies

This parameter requires a license for Embedded Coder and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function.

Programmatic Use

Parameter: FunctionWithSeparateData

Type: character vector

Value: 'off' | 'on'

Default: 'off'

`Memory section for initialize/terminate functions` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

Select how Embedded Coder applies memory sections to the subsystem initialization and termination functions.

Inherit from model: Apply the root model memory sections to the subsystem function code
Default: Do not apply memory sections to the subsystem system code, overriding any model-level specification
The memory section of interest: Apply one of the model memory sections to the subsystem

Tips

The possible values vary depending on what (if any) package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder) and Model Configuration Parameters: Code Generation (Simulink Coder).
If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model package contains.
These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).

Dependencies

This parameter requires a license for Embedded Coder software and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function or Reusable function.

Programmatic Use

Parameter: RTWMemSecFuncInitTerm

Type: character vector

Value:

'Inherit
                                        from model'

| 'Default' | 'The memory section of interest'

Default:

'Inherit
                                        from model'

`Memory section for execution functions` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

Select how Embedded Coder applies memory sections to the subsystem execution functions.

Inherit from model: Apply the root model memory sections to the subsystem function code
Default: Do not apply memory sections to the subsystem system code, overriding any model-level specification
The memory section of interest: Apply one of the model memory sections to the subsystem

Tips

The possible values vary depending on what (if any) package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder) and Model Configuration Parameters: Code Generation (Simulink Coder).
If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model package contains.
These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).

Dependencies

This parameter requires a license for Embedded Coder software and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function or Reusable function.

Programmatic Use

Parameter: RTWMemSecFuncExecute

Type: character vector

Value:

'Inherit
                                        from model'

| 'Default' | 'The memory section of interest'

Default:

'Inherit
                                        from model'

`Memory section for constants` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

Select how Embedded Coder applies memory sections to the subsystem constants.

Inherit from model: Apply the root model memory sections to the subsystem data
Default: Not apply memory sections to the subsystem data, overriding any model-level specification
The memory section of interest: Apply one of the model memory sections to the subsystem

Tips

The memory section that you specify applies to the corresponding global data structures in the generated code. For basic information about the global data structures generated for atomic subsystems, see Standard Data Structures in the Generated Code (Simulink Coder).
The possible values vary depending on what (if any) package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).
If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model package contains.
These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).

Dependencies

This parameter requires a license for Embedded Coder and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function and select the Function with separate data parameter.

Programmatic Use

Parameter: RTWMemSecDataConstants

Type: character vector

Value:

'Inherit
                                        from model'

| 'Default' | 'The memory section of interest'

Default:

'Inherit
                                        from model'

`Memory section for internal data` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

Select how Embedded Coder applies memory sections to the subsystem internal data.

Inherit from model: Apply the root model memory sections to the subsystem data
Default: Not apply memory sections to the subsystem data, overriding any model-level specification
The memory section of interest: Apply one of the model memory sections to the subsystem

Tips

The memory section that you specify applies to the corresponding global data structures in the generated code. For basic information about the global data structures generated for atomic subsystems, see Standard Data Structures in the Generated Code (Simulink Coder).
The possible values vary depending on what (if any) package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).
If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model package contains.
These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).

Dependencies

This parameter requires a license for Embedded Coder and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function and select the Function with separate data parameter.

Programmatic Use

Parameter: RTWMemSecDataInternal

Type: character vector

Value:

'Inherit
                                        from model'

| 'Default' | 'The memory section of interest'

Default:

'Inherit
                                        from model'

`Memory section for parameters` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

Select how Embedded Coder applies memory sections to the subsystem parameters.

Inherit from model: Apply the root model memory sections to the subsystem function code
Default: Not apply memory sections to the subsystem system code, overriding any model-level specification
The memory section of interest: Apply one of the model memory sections to the subsystem

Tips

The memory section that you specify applies to the corresponding global data structure in the generated code. For basic information about the global data structures generated for atomic subsystems, see Standard Data Structures in the Generated Code (Simulink Coder).
The possible values vary depending on what (if any) package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).
If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model package contains.
These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).

Dependencies

This parameter requires a license for Embedded Coder and an ERT-based system target file.
To enable this parameter, set Function packaging to Nonreusable function and select the Function with separate data parameter.

Programmatic Use

Parameter: RTWMemSecDataParameters

Type: character vector

Value:

'Inherit
                                        from model'

| 'Default' | 'The memory section of interest'

Default:

'Inherit
                                        from model'

Subsystem Reference

`Subsystem file name` — File name for referenced subsystem
string | character vector

Dependencies

To access this parameter, click the Convert button.

For more information on how to convert a subsystem to a referenced subsystem, see Convert an Existing Subsystem to a Referenced Subsystem.

Model Examples

Simulink Subsystem Semantics

This set of examples shows different types of Simulink® Subsystems and what semantics are used when simulating these Subsystems. Each example provides a description of the model and the subtleties governing how it will be executed.

Open Model

Converting Subsystems to Model Reference

Automate conversion of a model containing buses to use model reference.

Open Model

Single Hydraulic Cylinder Simulation

Use Simulink® to model a hydraulic cylinder. You can apply these concepts to applications where you need to model hydraulic behavior. See two related examples that use the same basic components: four cylinder model and two cylinder model with load constraints. Note: This is a basic hydraulics example. You can more easily build hydraulic and automotive models using Simscape™ Driveline™ and Simscape Fluids™.

Open Model

Block Characteristics

Data Types	`Boolean^[a]` \| `bus^[a]` \| `double^[a]` \| `enumerated^[a]` \| `fixed point^[a]` \| `half^[a]` \| `integer^[a]` \| `single^[a]` \| `string^[a]`
Direct Feedthrough	`no`
Multidimensional Signals	`limited^[a]`
Variable-Size Signals	`limited^[a]`
Zero-Crossing Detection	`no`
^[a] Actual data type or capability support depends on block implementation.

Extended Capabilities

C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.

Actual data type or capability support depends on block implementation.

HDL Code Generation
Generate Verilog and VHDL code for FPGA and ASIC designs using HDL Coder™.

HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.

HDL Architecture

Architecture Description

Module (default) Generate code for the subsystem and the blocks within the subsystem.

Architecture	Description
`Module` (default)	Generate code for the subsystem and the blocks within the subsystem.
`BlackBox`	Generate a black box interface. The generated HDL code includes only the input/output port definitions for the subsystem. Therefore, you can use a subsystem in your model to generate an interface to existing, manually written HDL code. The black-box interface generation for subsystems is similar to the Model block interface generation without the clock signals.
`No HDL`	Remove the subsystem from the generated code. You can use the subsystem in simulation, however, treat it as a “no-op” in the HDL code.

BlackBox

Generate a black box interface. The generated HDL code includes only the input/output port definitions for the subsystem. Therefore, you can use a subsystem in your model to generate an interface to existing, manually written HDL code.

The black-box interface generation for subsystems is similar to the Model block interface generation without the clock signals.

No HDL

Remove the subsystem from the generated code. You can use the subsystem in simulation, however, treat it as a “no-op” in the HDL code.

Black Box Interface Customization

For the BlackBox architecture, you can customize port names and set attributes of the external component interface. See Customize Black Box or HDL Cosimulation Interface (HDL Coder).

HDL Block Properties

General
AdaptivePipelining	Automatic pipeline insertion based on the synthesis tool, target frequency, and multiplier word-lengths. The default is `inherit`. See also AdaptivePipelining (HDL Coder).
BalanceDelays	Detects introduction of new delays along one path and inserts matching delays on the other paths. The default is `inherit`. See also BalanceDelays (HDL Coder).
ClockRatePipelining	Insert pipeline registers at a faster clock rate instead of the slower data rate. The default is `inherit`. See also ClockRatePipelining (HDL Coder).
ConstrainedOutputPipeline	Number of registers to place at the outputs by moving existing delays within your design. Distributed pipelining does not redistribute these registers. The default is `0`. For more details, see ConstrainedOutputPipeline (HDL Coder).
DistributedPipelining	Pipeline register distribution, or register retiming. The default is `off`. See also DistributedPipelining (HDL Coder).
DSPStyle	Synthesis attributes for multiplier mapping. The default is `none`. See also DSPStyle (HDL Coder).
FlattenHierarchy	Remove subsystem hierarchy from generated HDL code. The default is `inherit`. See also FlattenHierarchy (HDL Coder).
InputPipeline	Number of input pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is `0`. For more details, see InputPipeline (HDL Coder).
OutputPipeline	Number of output pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is `0`. For more details, see OutputPipeline (HDL Coder).
SharingFactor	Number of functionally equivalent resources to map to a single shared resource. The default is 0. See also Resource Sharing (HDL Coder).
StreamingFactor	Number of parallel data paths, or vectors, that are time multiplexed to transform into serial, scalar data paths. The default is 0, which implements fully parallel data paths. See also Streaming (HDL Coder).

If this block is not the DUT, the block property settings in the Target Specification tab are ignored. In the HDL Workflow Advisor, if you use the IP Core Generation workflow, these target specification block property values are saved with the model. If you specify these target specification block property values using hdlset_param, when you open HDL Workflow Advisor, the fields are populated with the corresponding values.

Target Specification
AdditionalTargetInterfaces	Additional target interfaces, specified as a character vector. To save this block property on the model, in the Set Target Interface task of the IP Core Generation workflow, corresponding to the DUT ports that you want to add more interfaces, select Add more.... You can then add more interfaces in the Add New Target Interfaces dialog box. Specify the type of interface, number of additional interfaces, and a unique name for each additional interface. Values: `''` (default) \| cell array of character vectors Example: `'{{'AXI4-Stream','InterfaceID','AXI4-Stream1'}}'`
ProcessorFPGASynchronization	Processor/FPGA synchronization mode, specified as a character vector. To save this block property on the model, specify the Processor/FPGA Synchronization in the Set Target Interface task of the IP Core Generation workflow. Values: `Free running` (default) \| `Coprocessing - blocking` Example: `'Free running'`
TestPointMapping	To save this block property on the model, specify the mapping of test point ports to target platform interfaces in the Set Target Interface task of the IP Core Generation workflow. Values: `''` (default) \| cell array of character vectors Example: `'{{'TestPoint','AXI4-Lite','x"108"'}}'`
TunableParameterMapping	To save this block property on the model, specify the mapping of tunable parameter ports to target platform interfaces in the Set Target Interface task of the IP Core Generation workflow. Values: `''` (default) \| cell array of character vectors Example: `'{{'myParam','AXI4-Lite','x"108"'}}'`
AXI4RegisterReadback	To save this block property on the model, specify whether you want to enable readback on AXI4 slave write registers in the Generate RTL Code and IP Core task of the IP Core Generation workflow. To learn more, see Model Design for AXI4 Slave Interface Generation (HDL Coder). Values: `'off'` (default) \| `'on'`
AXI4SlaveIDWidth	To save this block property on the model, specify the number of AXI Master interfaces that you want to connect the DUT IP core to by using the AXI4 Slave ID Width setting in the Generate RTL Code and IP Core task of the IP Core Generation workflow. To learn more, see Define Multiple AXI Master Interfaces in Reference Designs to access DUT AXI4 Slave Interface (HDL Coder). Values: `'off'` (default) \| `'on'`
AXI4SlavePortToPipelineRegisterRatio	To save this block property on the model, specify the number of AXI4 slave ports for which you want a pipeline register to be inserted by using the AXI4 Slave port to pipeline register ratio setting in the Generate RTL Code and IP Core task of the IP Core Generation workflow. To learn more, see Model Design for AXI4 Slave Interface Generation (HDL Coder). Values: `'off'` (default) \| `'on'`
GenerateDefaultAXI4Slave	To save this block property on the model, specify whether you want to disable generation of default AXI4 slave interfaces in the Generate RTL Code and IP Core task of the IP Core Generation workflow. Values: `'on'` (default) \| `'off'`
IPCoreAdditionalFiles	Verilog^® or VHDL^® files for black boxes in your design. Specify the full path to each file, and separate file names with a semicolon (;). You can set this property in the HDL Workflow Advisor, in the Additional source files field. Values: `''` (default) \| character vector Example: `'C:\myprojfiles\led_blinking_file1.vhd;C:\myprojfiles\led_blinking_file2.vhd;'`
IPCoreName	IP core name, specified as a character vector. You can set this property in the HDL Workflow Advisor, in the IP core name field. If this property is set to the default value, the HDL Workflow Advisor constructs the IP core name based on the name of the DUT. Values: `''` (default) \| character vector Example: `'my_model_name'`
IPCoreVersion	IP core version number, specified as a character vector. You can set this property in the HDL Workflow Advisor, in the IP core version field. If this property is set to the default value, the HDL Workflow Advisor sets the IP core version. Values: `''` (default) \| character vector Example: `'1.3'`
IPDataCaptureBufferSize	FPGA Data Capture buffer size, specified as a character vector. Use FPGA Data Capture to observe signals in a design when running on an FPGA. The buffer size uses values that are 1282^n, where n is an integer. By default, the buffer size is 128 (n=0). The maximum value of n is 13, which means that the maximum value for buffer size is 1048576 (=1282^13). Values: `''` (default) \| character vector Example: `'1.3'`

Restrictions

If your DUT is a masked subsystem, you can generate code only if it is at the top level of the model.

For more information, see:

External Component Interfaces (HDL Coder)
Generate Black Box Interface for Subsystem (HDL Coder)

PLC Code Generation
Generate Structured Text code using Simulink® PLC Coder™.

Fixed-Point Conversion
Design and simulate fixed-point systems using Fixed-Point Designer™.

Actual data type or capability support depends on block implementation.

Documentation

Subsystem, Atomic Subsystem, CodeReuse Subsystem

Description

Ports

Input

In — Signal input to a subsystem scalar | vector | matrix

Output

Out — Signal output from a subsystem scalar | vector | matrix

Parameters

Main

Show port labels — Display options for port labels FromPortIcon (default) | FromPortBlockName | SignalName

Programmatic Use

Read/Write permissions — Levels of access to contents of subsystem ReadWrite (default) | ReadOnly | NoReadOrWrite

Programmatic Use

Name of error callback function — Name of function to be called if error occurs '' (default) | function name

Programmatic Use

Permit hierarchical resolution — Resolution for workspace variable names All (default) | ExplicitOnly | None

Programmatic Use

Treat as atomic unit — Option to execute subsystem as one unit off (default) | on

Programmatic Use

Minimize algebraic loop occurrences — Option to eliminate artificial algebraic loops off (default) | on

Dependencies

Programmatic Use

Schedule As — Type of scheduling Sample Time (default) | Periodic Partition | Aperiodic Partition

Dependencies

Programmatic Use

Partition Name — Name of partition character vector

Dependencies

Programmatic Use

Sample time — Time interval -1 (default) | [Ts 0]

Dependencies

Programmatic Use

Variant control — Variant control (condition) expression Variant (default) | logical expression

Dependencies

Programmatic Use

Treat as grouped when propagating variant conditions — Option to treat subsystem as unit when propagating variant conditions on (default) | off

Programmatic Use

Code Generation

Function packaging — Code format Auto (default) | Inline | Nonreusable function | Reusable function

Tips

Dependencies

Programmatic Use

Function name options — How to name generated function Auto (default) | Use subsystem name | User specified

Dependencies

Programmatic Use

Function name — Name of function for subsystem code '' (default) | function name

Dependencies

Programmatic Use

File name options — How to name generated file Auto (default) | Use subsystem name | Use function name | User specified

Dependencies

Programmatic Use

File name (no extension) — Name of generated file '' (default) | file name

Dependencies

Programmatic Use

Function interface — Select to use arguments with generate function void_void (default) | Allow arguments (Optimized) | Allow arguments (Match graphical interface)

Dependencies

Programmatic Use

Function with separate data — Control code generation for subsystem off (default) | on

Dependencies

Programmatic Use

Memory section for initialize/terminate functions — Select how to apply memory sections Inherit from model (default) | Default | The memory section of interest

Tips

Dependencies

Programmatic Use

Memory section for execution functions — Select how to apply memory sections Inherit from model (default) | Default | The memory section of interest

Tips

Dependencies

Programmatic Use

Memory section for constants — Select how to apply memory sections Inherit from model (default) | Default | The memory section of interest

Tips

Dependencies

Programmatic Use

Memory section for internal data — Select how to apply memory sections Inherit from model (default) | Default | The memory section of interest

Tips

Dependencies

Programmatic Use

Memory section for parameters — Select how to apply memory sections Inherit from model (default) | Default | The memory section of interest

Tips

Dependencies

Programmatic Use

`In` — Signal input to a subsystem
scalar | vector | matrix

`Out` — Signal output from a subsystem
scalar | vector | matrix

`Show port labels` — Display options for port labels
`FromPortIcon` (default) | `FromPortBlockName` | `SignalName`

`Read/Write permissions` — Levels of access to contents of subsystem
`ReadWrite` (default) | `ReadOnly` | `NoReadOrWrite`

`Name of error callback function` — Name of function to be called if error occurs
`''` (default) | function name

`Permit hierarchical resolution` — Resolution for workspace variable names
`All` (default) | `ExplicitOnly` | `None`

`Treat as atomic unit` — Option to execute subsystem as one unit
off (default) | on

`Minimize algebraic loop occurrences` — Option to eliminate artificial algebraic loops
off (default) | on

`Schedule As` — Type of scheduling
`Sample Time` (default) | `Periodic Partition` | `Aperiodic Partition`

`Partition Name` — Name of partition
character vector

`Sample time` — Time interval
`-1` (default) | `[Ts 0]`

`Variant control` — Variant control (condition) expression
`Variant` (default) | logical expression

`Treat as grouped when propagating variant conditions` — Option to treat subsystem as unit when propagating variant conditions
`on` (default) | `off`

`Function packaging` — Code format
`Auto` (default) | `Inline` | `Nonreusable function` | `Reusable function`

`Function name options` — How to name generated function
`Auto` (default) | `Use subsystem name` | `User specified`

`Function name` — Name of function for subsystem code
`''` (default) | function name

`File name options` — How to name generated file
`Auto` (default) | `Use subsystem name` | `Use function name` | `User specified`

`File name (no extension)` — Name of generated file
`''` (default) | file name

`Function interface` — Select to use arguments with generate function
`void_void` (default) | `Allow arguments (Optimized)` | `Allow arguments (Match graphical interface)`

`Function with separate data` — Control code generation for subsystem
off (default) | on

`Memory section for initialize/terminate functions` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

`Memory section for execution functions` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

`Memory section for constants` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

`Memory section for internal data` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

`Memory section for parameters` — Select how to apply memory sections
`Inherit from model` (default) | `Default` | `The memory section of interest`

`Subsystem file name` — File name for referenced subsystem
string | character vector

C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.

HDL Code Generation
Generate Verilog and VHDL code for FPGA and ASIC designs using HDL Coder™.

PLC Code Generation
Generate Structured Text code using Simulink® PLC Coder™.

Fixed-Point Conversion
Design and simulate fixed-point systems using Fixed-Point Designer™.