For Each Subsystem

Subsystem that repeats execution on each element or subarray of input signals or mask parameters and concatenates results

expand all in page

Library:
Simulink / Ports & Subsystems
HDL Coder / Ports & Subsystems

Description

The For Each Subsystem block is a Subsystem block preconfigured as a starting point for creating a subsystem that repeats execution during a simulation time step on each element or subarray of an input signal or mask parameter array.

The set of blocks within the subsystem represents the algorithm applied to a single element or subarray of the original signal or mask parameter array. The For Each block inside the subsystem allows you to configure the decomposition of the subsystem inputs or mask parameters into elements or subarrays, and to configure the concatenation of the individual results into output signals. The block parameters Partition Dimension and Partition Width specify the dimension through which to slice the input signal or mask parameter array and the width of each slice, respectively. To partition a row vector, specify the Partition Dimension as 2. To partition a column vector, specify the Partition Dimension as 1. Use the parameter Partition Offset to specify a gap or an overlap between partitions. Specify a Number of iterations to limit processing to a subset of the data. To learn more about the block parameters, see For Each.

Inside this subsystem, each block that has states maintains separate sets of states for each element or subarray that it processes. Consequently, the operation of this subsystem is similar in behavior to copying the contents of the subsystem for each element in the original input signal or mask parameter array and then processing each element using its respective copy of the subsystem.

For certain models, the For Each Subsystem block also improves the code reuse in Simulink^® Coder™ generated code. Consider a model containing two reusable Atomic Subsystem blocks with the same scalar algorithm applied to each element of the signal. If the input signal dimensions of these subsystems are different, Simulink Coder generated code includes two distinct functions. You can replace these two subsystems with two identical For Each Subsystem blocks that are configured to process each element of their respective inputs using the same algorithm. In this case, Simulink Coder generated code consists of a single function parameterized by the number of input signal elements. This function is invoked twice, once for each unique instance of the For Each Subsystem block in the model. For each of these cases, the input signal elements have different values.

S-Function Support

The For Each Subsystem block supports both C-MEX S-functions and Level-2 MATLAB^® S-functions, provided that the S-function supports multiple execution instances using one of the following techniques:

A C-MEX S-function must declare ssSupportsMultipleExecInstances(S, true) in the mdlSetWorkWidths method.
A Level-2 MATLAB S-function must declare block.SupportsMultipleExecInstances = true in the setup method.

If you use the above specifications:

Do not cache run-time data such as DWork and Block I/O using global or persistent variables or within the user data of the S-function.
In a For Each Subsystem block, every S-function execution method from mdlStart up to mdlTerminate is called once for each element processed by the S-function. Consequently, you need to be careful not to free the same memory on repeated calls to mdlTerminate. For example, consider a C-MEX S-function that allocates memory for a run-time parameter within mdlSetWorkWidths. The memory only needs to be freed once in mdlTerminate. As a solution, set the pointer to be empty after the first call to mdlTerminate.

Limitations

The For Each Subsystem block has the following limitations and workarounds.

Limitation	Workaround
You cannot log bus or an array of bus signals directly in the For Each subsystem.	Use one of these approaches: Use a Bus Selector block to select the signals you want to log and mark those signals for signal logging. Attach the signal to an Outport block and log the signal outside the For Each subsystem.
You cannot log a signal inside a referenced model that is inside a For Each subsystem if either of these conditions exists: The For Each subsystem is in a model simulating in Rapid Accelerator mode. The For Each subsystem itself is in a model referenced by a Model block in Accelerator mode.	For the first condition, use Accelerator mode. For the second condition, use Normal or Rapid Accelerator mode.
You cannot log the states of the blocks in a For Each subsystem.	Save and restore the simulation state.
You cannot use Normal mode to simulate a Model block inside a For Each subsystem.	Use Accelerator or Rapid Accelerator mode.
Reusable code is generated for two For Each Subsystems with identical contents if their input and output signals are vectors (1-D or 2-D row or column vector). For n-D input and output signals, reusable code is generated only when the dimension along which the signal is partitioned is the highest dimension.	Permute the signal dimensions to transform the partition dimension and the concatenation dimension to the highest nonsingleton dimension for n-D signals.

The For Each Subsystem block does not support these features:

You cannot include these blocks or S-functions inside a For Each Subsystem:
- Data Store Memory, Data Store Read, or Data Store Write blocks
- The From Workspace block if the input is a Structure with Time that has an empty time field
- The To Workspace and To File data saving blocks
- Goto and From blocks that cross the subsystem boundary
- Referenced model with simulation mode set to Normal
- Shadow Inports
- ERT S-functions
For a complete list of the blocks that support the For Each Subsystem, type showblockdatatypetable at the MATLAB command line.

You cannot use these types of signals:
- Signals with an external storage class inside the system
- Frame signals on subsystem input and output boundaries
- Variable-size signals
Creation of a linearization point inside the subsystem
Propagating the Jacobian flag for the blocks inside the subsystem. You can check this condition in MATLAB using J.Mi.BlockAnalyticFlags.jacobian, where J is the Jacobian object. To verify the correctness of the Jacobian of the For Each Subsystem block:
- Look at the tag of the For Each Subsystem Jacobian. If it is “not_supported”, then the Jacobian is incorrect.
- Move each block out of the For Each Subsystem and calculate its Jacobian. If any block is " not_supported " or has a warning tag, the For Each Subsystem Jacobian is incorrect.
You cannot perform these types of code generation:
- Generation of a Simulink Coder S-function target
- Simulink Coder code generation under both of the following conditions:
  - A Stateflow^® or MATLAB Function block resides in the subsystem.
  - This block tries to access global data outside the subsystem, such as Data Store Memory blocks or Simulink.Signal objects of ExportedGlobal storage class.
- PLC code generation

Ports

Input

expand all

`In` — Signal input to Subsystem block
scalar | vector | matrix

Signal input to a Subsystem block, specified as a scalar, vector, or matrix. Placing an Inport block in a Subsystem block adds an external input port to the block. The port label matches the name of the Inport block.

Use Inport blocks to receive signals from the local environment.

Output

expand all

`Out` — Signal output from Subsystem block
scalar | vector | matrix

Signal output from a Subsystem block, returned as a scalar, vector, or matrix. Placing an Outport block in a Subsystem block adds an external output port to the block. The port label matches the name of the Outport block.

Use Outport blocks to send signals to the local environment.

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

Modeling Objects with Identical Dynamics Using For Each Subsystem

Model multiple objects with identical dynamics using the For Each Subsystem. The number of objects is parameterized by the length of the input signal.

Open Model

Vectorizing a Scalar Algorithm with For Each Subsystem

Use the For Each Subsystem. In this example the operations are performed on a vector for simplicity.

Open Model

Tiled Processing of 2D Signals with For Each Subsystem

Use the For Each Subsystem. In this example the operations are performed on matrices.

Open Model

Neighborhood Processing Using For Each Subsystems

Use the For Each Subsystem block to process submatrices data when neighboring submatrices overlap each other. To demonstrate this data processing approach, the example implements the image edge detection with linear filters using the For Each Subsystem block. Each For Each Subsystem block has a For Each block that needs to be configured for partitioning and concatenation.

Open Model

Temperature Control System Communicating with Messages

Use message communication within a distributed system where the controller manages multiple incoming messages from different senders in an iterative manner and sends messages to communicate commands to the different receivers. The example uses a model of a control system managing temperatures in two different rooms with separate thermostats. The algorithmic modeling of the components basically follows the Stateflow example Model Bang-Bang Temperature Control System (Stateflow), while the communication between the components is modeled using Simulink® messages and SimEvents® blocks. The referenced models Controller and Thermometer, colored in blue, are software components expected to generate standalone code, while the other components model the environment.

Block Characteristics

Data Types	`Boolean^[a]` \| `bus^[a]` \| `double^[a]` \| `enumerated^[a]` \| `fixed point^[a]` \| `half^[a]` \| `integer^[a]` \| `single^[a]`
Direct Feedthrough	`no`
Multidimensional Signals	`limited^[a]`
Variable-Size Signals	`no`
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 code generation 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.

When you generate HDL code for the For Each Subsystem, the code generator uses a for-generate loop that iterates through elements of the input and output signals. The for-generate loop improves readability and reduces the number of lines of code, which can otherwise result in hundreds of lines of code for large vector signals.

You can use a nonzero partition offset for HDL code generation. The code generator supports partitioning of mask parameters inside a For Each Subsystem. Inside the For Each Subsystem, use the mask parameter as the Constant value in Constant blocks or as the Gain parameter in Gain blocks.

Limitations

You cannot use the For Each Subsystem block as the DUT.
You must clear the Show partition index output port (zero-based indexing) check box on the For Each block for HDL code generation.

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

Target Specification

This block cannot be the DUT, so the block property settings in the Target Specification tab are ignored.

Complex Data Support

The block does not support complex data signals for HDL code generation. To input complex signals, you can convert this signal to an array of signals, and then input to the block. To learn more, see Generate HDL Code for Blocks Inside For Each Subsystem (HDL Coder).

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

Actual data type support depends on block implementation.

Documentation

For Each Subsystem