Scheduler

On this page…
Base Rate Running Target Applications on Multicore Processors Avoiding Lock-Up in Free-Running, Multirate, Multitasking Models

Base Rate

The base rate in the model maps to a thread and runs as fast as possible. The base rate priority selection in the OS tab allows you to set a static priority for the base rate task. By default, this rate is 40.

The process running single-tasking models has Default scheduling policy when model is single-tasking or there is a single rate in the model. Static priority of the process is 0 in this case.

Back to Top

Running Target Applications on Multicore Processors

Introduction

This section provides a variation of the process described in Configuring Models for Targets with Multicore Processors.

This section shows you how to:

• Configure a multirate model

• Generate a multithreaded application from that model

So that the resulting application is enabled for concurrent multicore execution on an embedded target running Linux or VxWorks.

This process uses the idelink_ert.tlc or idelink_grt.tlc system target files, which enable you to:

• Use Eclipse IDE to manage projects for Linux targets (Support for this capability is only available on 32-bit host platforms)

• Cross-compile from a Windows host to a Linux target

• Set thread priority using a Target Preference block

• Use VxWorks

Note   For using VxWorks, also see Tutorial: Building and Running Embedded Software on VxWorks.

Looking at an Example Model

Before setting up your own model, consider the sldemo_concurrent_execution demo model, which is referenced by Configuring Models for Targets with Multicore Processors.

The sldemo_concurrent_execution.mdl is a useful example to look at because:

• The model is partitioned using Model blocks that can potentially execute concurrently.

• You can look at the Map Blocks To Tasks pane in the Concurrent Execution window to see how the tasks are configured for concurrent execution.

However, you cannot run an unmodified version of the sldemo_concurrent_execution model on an embedded target running Linux or VxWorks.

To modify the demo model so you can use it in Setting Up the Model and Deploying the Model to Your Target, complete the following procedures:

• Updating the Plant Model Block

• Updating the Compensator Model Block

• Verifying that Models are Mapped Correctly

These procedures guide you through the processes of discretizing models and matching sample times of blocks with models.

Updating the Plant Model Block.  

1. In the sldemo_concurrent_execution model, open the "Plant" Model block (sldemo_concurrent_execution_plant.mdl).

2. Discretize the Plant model. Replace the Integrator blocks, "x1" and "x2", with equivalent discrete time blocks (such as the Discrete Time Integrator block) or use the Model Discretizer.

3. Prevent modeling constraints by matching the sample time of the "x1" and "x2" blocks with the model: Open the "x1" and "x2" blocks and change the Sample time parameters to 0.1. Matching the sample times to the model can also be accomplished using Rate Transition blocks.

4. Convert blocks with continuous sample times (Sample time = 0) to inherited sample times (Sample time = -1). Open the "u1", "u2" and "x" blocks. For each one, click the Signal Attributes tab, then change Sample time to -1.

5. Save your changes to the blocks and the model.

Updating the Compensator Model Block.  

1. In the sldemo_concurrent_execution model, open the "Compensator" Model block (sldemo_concurrent_execution_compensator.mdl).

2. Discretize the Compensator model. Replace the Integrator block, "c", with an equivalent discrete time block (such as the Discrete Time Integrator block) or use the Model Discretizer.

3. Prevent modeling constraints by matching the sample time of the "c" block with the top model: Open the "c" block and change the Sample time parameters to 0.1. Matching the sample times to the top model, sldemo_concurrent_execution.mdl, can also be accomplished using Rate Transition blocks.

4. Convert blocks with continuous sample times (Sample time = 0) to inherited sample times (Sample time = -1). Open the "y1", "y2", and "x" blocks. For each one, click the Signal Attributes tab, then change Sample time to -1.

5. The following parameters cannot both be enabled when you build the model. Open the Configuration Parameters (Ctrl+E) and verify that one of the following parameters is disabled (unchecked):

   • Minimize algebraic loop occurrences, located on the Model Referencing pane.

   • Single output/update function, located on the Code Generation > Interface pane.

6. Save your changes to the blocks and the model.

Verifying that Models are Mapped Correctly.  Open and inspect the Task editor to ensure that the models are appropriately mapped:

1. In the Simulink model editor for sldemo_concurrent_execution.mdl, select View > Model Explorer (Ctrl + H).

2. In Model Explorer, expand the top model, sldemo_concurrent_execution.

3. Under the top model, select Configuration (Active), then click Concurrent Execution in the second column. In the third column, click the ConfigureTasks and Map Blocks to Tasks button.

4. Click Map Blocks To Tasks. Inspect that the mapping of the models is correct as described in Design Considerations.

The sldemo_concurrent_execution demo model is ready for you to use in Setting Up the Model and Deploying the Model to Your Target.

Setting Up the Model

This procedure explains how to set up a model for a multicore processor.

1. Apply the recommendations in Design Considerations to your multirate Simulink model. Or, refer to the sldemo_concurrent_execution demo model.

2. Add a Target Preferences block to your model as described in Target Preferences .

3. In the Target Preferences block, set Operating System to Linux or VxWorks.

4. If your model uses a Rate Transition block to transition between rates, then open the Rate Transition block and clear the Ensure deterministic data transfer checkbox so that the block uses the most recent data available.

5. Configure the model for concurrent execution:

   1. In the Simulink model editor, select View > Model Explorer (Ctrl + H).

   2. In Model Explorer, expand the top model.

   3. Under the top model, right click Configuration (Active) and select Convert to Configuration for Concurrent Execution. (In the sldemo_concurrent_execution demo model, this step has already been performed.)

6. For each referenced model in the model hierarchy that you want to run with concurrent execution:

   1. Copy the Target Preferences block from the top model to the referenced model.

   2. Repeat steps 4 through 5.

7. Select the configuration set of the model at the top of the model hierarchy. In the second column, select the Concurrent Execution node. A Concurrent Execution pane appears in the third column. (In the sldemo_concurrent_execution demo model, this step has already been performed.)

8. In the Concurrent Execution pane in the third column, select the This is the top of the model hierarchy check box, and click the ConfigureTasks and Map Blocks to Tasks button. (In the sldemo_concurrent_execution demo model, this step has already been performed.)

9. The Concurrent Execution configuration parameters dialog box is displayed. Click Apply.

Deploying the Model to Your Target

In your model, click the build button or enter Ctrl+B. The software performs the actions you selected for Build action in the model Configuration Parameters, under Code Generation > IDE Link.

For more information on the structure of the code, please refer to Building and Downloading the Model to a Multicore Target. As mentioned in that section, the coder product generates all target-dependent code for thread creation, thread synchronization, interrupt service routines, and signal handlers and data transfer. For each periodic task, Simulink Coder combines the output and update methods of the blocks mapped to that task and binds these methods to a target-specific thread.

Note   The idelink_ert.tlc or idelink_grt.tlc system target files do not support Continuous times.

Generated Code

For idelink_ert.tlc or idelink_grt.tlc system target files, the generated code from a mapped model creates a thread for each task and automatically leverages the threading APIs supported by the operating system running on the target.

• If the target platform is running Windows , the generated code will use Windows threads.

• If the target platform is running Linux or VxWorks , the generated code will use POSIX^® threads (pthreads).

The following table summarizes the differences in the generated code between the target platforms.

Aspect of Concurrent Execution	Linux	VxWorks
Periodic triggering event	POSIX timer	POSIX timer
Aperiodic triggering event	POSIX real-time signal	POSIX real-time and non-real-time signal
Aperiodic trigger	For blocks mapped to an aperiodic task: thread waiting for a signal For blocks mapped to an aperiodic trigger: signal action	For blocks mapped to an aperiodic task: thread waiting for a signal. For blocks mapped to an aperiodic trigger: signal action
Threads	POSIX	POSIX
Thread priority	Assigned based on Target Preference Block setting	Assigned based on Target Preference Block setting
Example of overrun detection	Yes	Yes

The coder also ensures that data transfer between concurrently executing tasks behave as described in Data Transfer Options. The coders ensure data transfer using the following APIs on supported targets.

API	Linux Implementation	VxWorks
Data protection API	pthread_mutex_init pthread_mutex_destroy pthread_mutex_lock pthread_mutex_unlock	pthread_mutex_init pthread_mutex_destroy pthread_mutex_lock pthread_mutex_unlock
Synchronization API	sem_init sem_destroy sem_wait sem_post	sem_open sem_unlink sem_wait sem_post

Back to Top

Avoiding Lock-Up in Free-Running, Multirate, Multitasking Models

This section applies when the following conditions are true:

• The model is a multirate multitasking model

• In the Target Preferences block, on the Board pane, the Operating system parameter is set to Linux

• In the Target Preferences block, on the Linux pane, the Scheduling Mode parameter is set to free-running

Because of the rate monotonic scheduling requirement in Linux, the scheduler runs threads with a SCHED_FIFO scheduling policy. A process scheduled with SCHED_FIFO prevents other process from running while it is ready to run. Therefore, if the model does not contain any blocking peripherals, the entire Linux system can become unresponsive while you are running the generated code. Such lock-up can even preempt the shell window from running. To avoid this lock-up, apply one of the following solutions:

• Set Scheduling Mode to real_time.

• Include a blocking device driver, such as a UDP block, in your model that suspends running thread while data is not available.

• Raise the shell window priority above the base-rate priority so you can kill the process running with SCHED_FIFO class.

Back to Top

Preparing Models to Run on Linux

Example: Build Generated Code on a BeagleBoard Running Linux

© 1984-2012- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS