|On this page…|
The simulation itself does not require or use multicore target capabilities as configured in the Concurrent Execution dialog box. In general, use these concurrent execution modeling concepts for real-time system design. Note that these concepts are not helpful if you want to improve the performance of a Simulink® simulation on a non-real-time host computer. Simulink tries to optimize use of host computers, regardless of the modeling pattern you use. For more information on these techniques, see Performance.
Consider the model sldemo_concurrent_execution. To understand simulation results, compare the signal x in two scenarios:
Baseline 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 with no user defined tasks or triggers. Because this model contains only one sample time (continuous sample time), the sample-time analysis configures the target with one system task and implicitly assigns 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. Simulation of the model should produce the same numeric results as if the model is not configured for concurrent execution.
Configure the model to record logged data in the Simulation Data Inspector by clicking the Simulation Data Inspector arrow in the tool bar and selecting Send Logged Workspace Data to Data Inspector. (Alternatively, in the Configuration Parameters dialog box, select the Data Import/Export > Record logged workspace data in Simulation Data Inspector check box). After you enable the Simulation Data Inspector to record logged data, click Simulate > Run to simulate the model using the single task configuration. After simulation, launch the Simulation Data Inspector by clicking the Simulation Data Inspector button in the editor tool bar. Observe that the tool has recorded 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 three times.
Select the first added task and label it ControllerA.
Select the second added task and label it ControllerB.
Select the third added task and label it Plant.
In the Tasks and Mapping pane, assign the ControllerA block to execute within the ControllerA task, the ControllerB block to execute within the ControllerB task, and the Periodic and Compensator blocks to execute within the Plant task. Assign the Interrupt block to the Interrupt trigger.
Simulate the model again.
After simulation completes, inspect the results for the baseline 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 baseline 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 (maximum delay), 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.