Using a dataflow domain, you can model and simulate a computationally intensive signal processing or multirate signal processing system. Dataflow domains simulate using a model of computation synchronous dataflow, which is data-driven and statically scheduled.
There are two primary reasons to use a dataflow domain in your model.
Improve simulation throughput with multithreaded execution.
A dataflow domain leverages the multicore CPU architecture of the host computer and can improve simulation speed significantly. The domain automatically partitions your model and simulates the system using multiple threads. By adding latency to your system, you can further increase concurrency and improve the simulation throughput of your model.
Automatically infer signal sizes for frame-based multirate models.
When the Automatic frame-size calculation parameter is enabled, dataflow domains automatically calculate frame sizes and insert buffers into your model, avoiding signal size propagation errors in multirate signal processing systems.
Specifying Dataflow Domains
To create a dataflow domain, use the Dataflow Subsystem block. The domain of the Dataflow Subsystem block is preconfigured.
To convert an existing subsystem into a Dataflow Subsystem:
In the Execution tab of the Property Inspector, select the Set execution domain check box.
If the Property Inspector is not visible, in the Modeling tab, under Design, select Property Inspector. For more information on the Property Inspector, see Setting Model and Block Properties with Property Inspector (Simulink).
With the subsystem selected, set the Domain to
Inside the subsystem, in the lower left corner of the model canvas, there is now a icon, which indicates that the subsystem is a Dataflow subsystem.
Dataflow domains are supported only at the subsystem level. You cannot set the
Domain of a top-level model to
Simulation of Dataflow Domains
Simulation of dataflow domains leverages the multicore CPU architecture of the host computer. It automatically partitions your model and simulates the subsystem using multiple threads.
The first time you simulate a dataflow domain, the simulation is single threaded. During this simulation, the software performs a cost analysis. The next time the model compiles, the software automatically partitions the system for multithreaded execution.
Each time you make a change inside the dataflow domain, the next simulation may be single threaded to allow the software to perform a new cost analysis. Following a cost analysis simulation, the next time the model compiles, the software repartitions the domain and subsequent simulations are multithreaded.
Some blocks and language features are not supported for multithreaded simulation. If a dataflow subsystem contains blocks or language features that do not support multithreaded simulation, Simulink® issues a warning and the subsystem always simulates in a single thread.
The To Workspace (Simulink) block and signal logging inside a Dataflow Subsystem block support multithreaded simulation. However, during multi-threaded execution, the output of the To Workspace block or logged signal data may be different than the single-threaded execution. This is because of the distribution of the pipeline delays inside the Dataflow Subsystem block for multithreading. These delays impact the output due to the latencies in the model. You can visualize these delays and the relationship between the output of the To Workspace block or the logged signals and the delays.
If a dataflow subsystem contains blocks or language features that are not supported inside a dataflow subsystem, Simulink generates an error. For more information, see Unsupported Simulink Software Features in Dataflow Domains.
To increase the throughput of a system, it can be advantageous to increase the latency of a system. Specify the Latency value in the Execution tab of the Property Inspector.
When latency is introduced into a dataflow domain, the output of the dataflow subsystem is marked with a delay icon on the model canvas. Changes to the model within the dataflow subsystem may require a cost analysis and repartition.
If your model contains several dataflow subsystems, you can use the Performance Advisor to analyze and suggest a latency for each of the dataflow subsystems in a single step. To find the optimal latency settings for the Dataflow subsystems in your model, open the Performance Advisor. In the Performance Advisor > Simulation > Checks that Require Simulation to Run folder, run the Check Dataflow Domain Settings check.
For more information on types of parallelism in dataflow domains, see Multicore Simulation and Code Generation of Dataflow Domains.
You can also use the following settings for the optimal simulation performance. These settings are also provided in the toolstrip when you perform multicore analysis, see Perform Multicore Analysis for Dataflow.
Set Compiler optimization level (Simulink) to
Optimizations on (faster runs).
set_param(gcs, 'SimCompilerOptimization', 'on')
Disable the Ensure responsiveness (Simulink) parameter.
set_param(gcs, 'SimCtrlC', 'off')
Set Wrap on overflow (Simulink) to
set_param(gcs, 'IntegerOverflowMsg', 'none')
Set Saturate on overflow (Simulink) to
set_param(gcs, 'IntegerSaturationMsg', 'none')
To further improve the simulation performance, follow the steps presented in Perform Multicore Analysis for Dataflow.
Automatic Frame Size Calculation
Simulink can automatically calculate the frame sizes needed for each block in a frame-based signal processing system, and insert buffers where needed. To enable automatic frame size calculation in a Dataflow subsystem, select Automatic frame size calculation in the Execution tab of the Property Inspector.
Features Supported for Automatic Frame Size Calculation. Automatic frame size calculation is supported only for signals whose data types are one of the numeric types (built-in integer, double, single, or fixed-point). Signals using an enumerated type or whose data type is a bus are not supported.
Frame size calculation supports only two-dimensional signals.
Unsupported Simulink Software Features in Dataflow Domains
Dataflow subsystems do not support the following Simulink software features.
|Variable-size signals||The software does not support variable-size signals. A variable-size signal is a signal whose size (number of elements in a dimension), in addition to its values, can change during model execution.|
|Referenced models||Model (Simulink) blocks are not supported in dataflow domains.|
|Nonvirtual Simulink subsystems, including Triggered Subsystem (Simulink), Enabled Subsystem (Simulink), and atomic subsystems||Only virtual subsystems are supported in dataflow domains.|
|Blocks with non-constant or non-inherited sample times||All sample times inside dataflow subsystems must be inherited
Blocks in the Continuous (Simulink) library are not supported in dataflow domains.
Simulink indicates in the model canvas at edit-time that these blocks are not supported by highlighting the block in orange.
|Data Store blocks|
Data Store Memory, Data Store Read, and Data Store Write blocks are not supported inside dataflow subsystems.
|Subset of Simulink blocks|
If a dataflow subsystem contains blocks or language features that are not supported, Simulink generates an error when the model compiles.
For some blocks, such as Scope blocks, Simulink indicates in the model canvas at edit-time that they are not supported by highlighting the block in orange.
|Stateflow® charts||Stateflow charts are not supported inside dataflow subsystems.|
|SimEvents® blocks||SimEvents blocks are not supported inside dataflow subsystems.|
|HDL code generation||Only C/C++ code generation is supported for models with dataflow subsystems.|