|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
| On this page… |
|---|
A model configured for concurrent execution is defined as a model designed to execute concurrently on a real-time multicore target. In this situation, different pieces of the model ultimately execute in concurrent threads on the target environment. Modeling for concurrent execution allows the designer to factor in the effect of the concurrent execution semantics within the model, to simulate and to provide initial conditions for data transfer points.
Note The simulation itself does not require a multicore host. The current simulation engine uses only one thread to simulate. |
Modeling for concurrency is an iterative process. It ultimately deploys a model on a multicore target environment while making the best use of the computational power provided by the multiple cores. To support the iterative workflow, Simulink provides a mapping interface that allows you to map the potential concurrency in the design to the actual concurrency available on the target. A model configured for concurrent execution consists of three parts:
A model that has identified blocks for concurrent execution
A description of the available concurrency in terms of the number of tasks and their periodicities
A mapping that places the identified blocks in the model into actual tasks for concurrent execution
These parts constitute a mapped model. To manage mapped models, Simulink software provides:
Explicit control over task configuration and how blocks are mapped to tasks
Control over how data is communicated between tasks
Simulation of a mapped model that allows you to validate a desired functionality against the data transfer requirements of a particular mapping
To validate if a particular mapping is an acceptable design, first validate that the mapped model produces the desired simulation traces. Simulation results vary from mapping to mapping because each mapping imposes communication (data transfer) requirements that might cause the Simulink software to treat certain signal lines as delays for data transfer. Ultimately, however, you must evaluate the mapping on the target, and profile the behavior to measure whether the mapping meets the computational requirements and makes good use of the available computational power of the target platform. This evaluation and profiling are beyond the scope of the software.
To use the software mapping interface, a model must first specify opportunities for concurrency by identifying blocks for concurrent execution. Use Model blocks (referenced models) to identify potential opportunities for concurrent execution. A Model block defines a unit of functionality that the software can map for execution in one or more target tasks. More precisely, you can map a multirate Model block that contains N rates to exactly N tasks, the periodicity of which agree with the respective rates. You can map several Model blocks to the same task. Map a Model block that contains continuous blocks to a task, the period of which agrees with the fundamental sample time of the model. You can specify the fundamental sample time of the model in the Fixed-step size (fundamental sample time) of the Solver pane in the Configuration Parameters dialog box.
Because Model blocks must be used to express opportunities for concurrency, a design must consist entirely of Model blocks. You can also use virtual connectivity blocks to organize the block diagram, including:
Ground and Terminator blocks
Virtual subsystem blocks that contain permitted blocks
A model configured for concurrent execution reports an error diagnostic if any other blocks are detected. Place all other blocks in one or more referenced models.
Also consider signal lines when designing for concurrent execution. Depending on the mapping, any signal line can potentially be identified as a data transfer point. In particular, if the source port of a signal originates in a block from one task and the destination port is to a block in another task, the Simulink software identifies that signal as a data transfer point.
An algebraic constraint or algebraic loop might impose tight coupling between tasks and can lead to severe computational penalties. Therefore, a model configured for concurrent execution cannot contain algebraic loops or algebraic constraints that originate from physical modeling in a referenced model. This condition makes an algebraic loop fully contained in a task.
However, the use of Model blocks might lead to artificial algebraic loops. This condition might occur if Simulink cannot identify if a break point is encapsulated within a referenced model. In such situations, use one of the following methods to remove artificial algebraic loops:
In the referenced model Configuration Execution dialog box, select Model Referencing > Minimize algebraic loop occurrences.
Insert a Memory or Unit Delay block as the first block at the relevant input port of the referenced model.
Additionally, if the model is configured for the Embedded Coder target (ert.tlc), in the Configuration Parameters dialog box, clear the Code Generation > Interface > Single output/update function check box. This last operation prevents optimizations that can lead to artificial algebraic loops.
When modeling for concurrent execution, configure the model to use the fixed-step solver.
Do not use the following modes of simulation for models in the concurrent execution environment:
External mode
Logging to MAT-files
Processor-in-the-loop (PIL) simulation mode
Software-in-the-loop (SIL) simulation mode
If you are simulating your model using Rapid Accelerator mode, the top-level model cannot contain a root level Inport block that outputs function calls.
In the Configuration Parameters dialog box, set the Diagnostics > Sample Time > Multitask conditionally executed subsystem and Diagnostics > Data Validity > Multitask data store parameters to error.
In addition, for all Rate Transition blocks within the Model blocks:
Select the Ensure data integrity during data transfer check box.
Clear the Ensure deterministic data transfer (maximum delay) check box.
 | Introduction | Modeling for Concurrent Execution |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
