|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
| On this page… |
|---|
A model configured for concurrent execution is a model that is designed to execute concurrently on a real-time multicore target. Simulink enables you to simulate such models and observe the effects of task-to-task data transfer. You can also observe how this transfer can impact the numerical characteristics of the model.
Note The simulation itself does not require a multicore target. The number of tasks that you use to simulate the design is determined by other factors and does not impose any requirements on the number of tasks modeled by the design. Factors that influence the concurrency of the simulation include the use of the Basic Linear Algebra Subprograms (BLAS) library, Rapid Accelerator mode, and the MATLAB parfor command. |
Consider the model sldemo_concurrent_execution. To understand simulation results, compare the signal x in two scenarios:
Default configuration — The target has exactly one periodic task and all blocks are mapped to execute within this task. In this configuration, the target does not allow for any concurrent execution.
Sample configuration — The target has three periodic tasks and all blocks are mapped to execute concurrently in these tasks.
In the following example, the model is configured as described in Baseline Analysis Using Configuration Defaults. Because this model contains only one sample time (continuous sample time), the automatic analysis configures the target with one task and maps all blocks to run in that task. The period of the task is selected as 0.1, which agrees with the fixed-step size of the model. Because the design has only one task, no task-to-task data transfer is needed. Therefore, simulation of the model should produce the same numeric results as if the model is not configured for concurrent execution.
Note Configuring a model with automatic analysis always configures a model to minimize task-to-task communication requirements. In particular, only those communications that require rate transitions are included in the design. |
Configure the model to inspect data using the Simulation Data Inspector from the Data Input and Output pane of the Configuration Execution dialog box. After you enable the Simulation Data Inspector, click Simulate > Start> to simulate the model using the single task configuration. After simulation, the Simulation Data Inspector should automatically launch and record the simulation results for the signal labeled x.
In the Concurrent Execution dialog box, create two additional tasks and map the ControllerA block to the first additional task and the ControllerB block to the second additional task.
Open the Concurrent Execution dialog box.
Click the Add Task button twice.
Select the first added task and label it ControllerA.
Select the second added task and label it ControllerB.
In the Map blocks to tasks pane, check that the ControllerA block is assigned to execute within the ControllerA task and the ControllerB block is assigned to execute within the ControllerB task.
Simulate the model again.
After simulation completes, compare the results for the default and custom configurations using the Simulation Data Inspector.
To understand the source of the phase margin, observe that:
For the first run of the model, signal x, identified by the black line, shows a default task configuration.
In the second run of the model, signal x, identified by the red line, shows a custom task configuration and the effects of communication latencies from lines crossing task boundaries. This is different from the first run, which has only one periodic task and therefore, no communication latencies.
The default setting for data transfer is to ensure determinism, so the data transfer is deterministic (see Data Transfer Options).
Because the data transfer is deterministic, the simulated model takes into account a unit delay to capture the effects of data transfer. This delay causes a small phase margin in the mapped design. The delay agrees with the step size of the model, which is 0.1. This delay is the least possible delay that the software can impose on the signal.
The software determines data transfer based on how the blocks are mapped to tasks. When a model is simulated, either from an update diagram or upon code generation, Simulink software examines the block-to-task mapping and determines which signals must be configured for task-to-task data transfer. The software considers only the signals where the source of the signal originates from one task and the destination of the signal resides in a different task. You can specify global options that control data transfer (see Data Transfer Options). You can also override these options for each signal from the Data Transfer pane of the Signal Properties dialog box.
Therefore, the block-to-task mapping dictates which blocks execute in which tasks. Consequently, this mapping also dictates which signals you configure for task-to-task data transfer.
 | Customizing Concurrent Execution Settings | Building and Downloading the Model to a Multicore Target |  |
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 |
