The Simulink® Real-Time™ kernel has three mutually exclusive execution modes. You can execute the real-time application in one non-real-time mode and in two real-time modes.
Interrupt mode — To use this real-time mode,
on the Simulink Real-Time Options pane in the
Configuration Parameters dialog box, set Execution mode to
In this mode, the scheduler implements real-time single-tasking and multitasking execution of single-rate or multirate systems, including asynchronous events (interrupts). This implementation allows you to interact with the target computer while the real-time application is executing at high sample rates.
Polling mode — To use this real-time mode:
Use multicore target computer hardware.
Real-Time Explorer, check that the Multicore
CPU target setting is set to
the target computer that you intend to use.
On the Simulink Real-Time Options pane
in the Configuration Parameters dialog box, set Execution
Enable polling by setting the
-axpcCPUClockPoll to a nonzero value.
In this mode, the kernel executes real-time applications at sample times close to the limit of the CPU. Using polling mode with high-speed and low-latency I/O boards and drivers allows you to achieve real-time application sample times that you cannot achieve using interrupt mode. Because polling mode disables interrupts on the processor core where the model runs, it imposes restrictions on the model architecture and on target communication.
Freerun mode — To use this non-real-time mode, in the Configuration Parameters dialog box:
On the Simulink Real-Time Options pane,
set Execution mode to
On the Solver pane, clear the check box for Treat each discrete rate as a separate task.
In this mode, the real-time application thread does not wait
for the timer. The kernel runs the application as fast as possible.
If the real-time application has conditional code, the time between
each execution can vary. Multirate models cannot be executed in
When you set Execution mode to
the Simulink Real-Time Options pane in the Configuration
Parameters dialog box, interrupt mode is the real-time execution mode
set by default. This mode provides the greatest flexibility. Choose
this mode for real-time applications that execute at the given base
sample time without overloading the CPU.
In interrupt mode, the scheduler implements real-time single-tasking and multitasking execution of single-rate or multirate systems, including asynchronous events (interrupts). Also, background tasks like target communication or updating the target display run in parallel with sample-time-based model tasks. This implementation allows you to interact with the target system while the real-time application is executing at high sample rates. Interaction is made possible by an interrupt-driven real-time scheduler responsible for executing the various tasks according to their priority. The base sample time task can interrupt other tasks (larger sample time tasks or background tasks). Execution of the interrupted tasks resumes when the base sample time task completes operation. This capability gives a quasiparallel priority execution scheme.
In interrupt mode, the kernel is close to optimal for executing code on a PC-compatible system. However, using interrupt mode introduces an overhead, or latency, that reduces the minimal possible base sample time. The overhead is the sum of various factors related to the interrupt-driven execution scheme, such as interrupt controller latency, interrupt handler latency, and CPU latency. The overhead is referred to as overall interrupt latency.
The overall latency of interrupt mode is equivalent to a Simulink model containing a hundred nontrivial blocks. At least 5% of headroom is required because the CPU must also service lower priority tasks. This requirement can cause additional cache misses and therefore nonoptimal execution speed.
Polling mode for the kernel is designed to execute real-time applications at sample times close to the limit of the CPU. Polling mode with high-speed and low-latency I/O boards and drivers allows you to achieve smaller sample times for real-time applications. You cannot achieve these smaller sample times using the interrupt mode of the Simulink Real-Time software.
Polling mode has two main uses:
Control systems — Control system models of
average model size and I/O complexity that are executed at small sample
Ts = 10–50
DSP systems — Sample-based DSP system models
of average model size and I/O complexity that are executed at high
sample rates (
20–100 kHz). DSP models mainly process
audio and speech data.
Polling mode for the kernel does not have the latency that interrupt mode does. It is sometimes seen as a “primitive” or “brute force” real-time execution scheme. When a real-time application executing in interrupt mode at a given sample time overloads the CPU, switching to polling mode is often the only alternative.
In interrupt mode, when a CPU has finished executing the real-time code, it cedes the rest of its execution time to the operating system. The operating system can use this time to execute other tasks, such as background or I/O tasks. When the next execution step is scheduled, the timer generates an interrupt, and Simulink Real-Time executes the next step.
In polling mode, however, when the CPU has finished executing the real-time code, the CPU does not cede time to other tasks. Instead, it does not do anything besides checking (polling) the time value to determine whether it is time to run the next execution step. Once this time arrives, it executes the next step and the process continues.
The latency associated with interrupts is not incurred because no timer interrupts are involved on this core. However, one core of the target computer is occupied with running the base rate, irrespective of how long it takes to run the actual real-time task.
The polling execution scheme does not depend on interrupt sources to notify the code to continue calculating the next model step. The base rate of the real-time code is executed on one core of the multicore processor, timed by the polling loop. Background tasks and model tasks other than the base rate task are executed on the other cores. For efficiency, put only the most critical code into the base rate task.
If you use Simulink Real-Time concurrent execution to execute your model, you can have multiple base rate tasks. The CPU scheduler arbitrarily selects one of these tasks to run in the polling loop.
Before considering polling mode, do the following:
Optimize the model execution speed — To find possible speed optimizations using alternative blocks, use Performance Advisor or the profiler. If the model contains continuous states, discretizing these states reduces model complexity significantly. You can avoid a costly fixed-step integration algorithm. If continuous states cannot be discretized, use the integration algorithm with the lowest order that still produces the required numeric results.
Use the fastest available CPU — Use the CPU with the highest clock rate available for a given target computer form factor. For the desktop form factor, use a CPU with a clock rate above 3 GHz. For a model of a mobile system (e.g., PC/104 form factor), use a CPU with a clock rate above 1 GHz.
Use the lowest latency I/O modules and drivers available — Many real-time applications communicate with I/O modules over a PCI bus. Each register access introduces a comparably high latency time. Using the lowest latency I/O modules and drivers available is crucial.
Consider running less critical code at a slower rate, taking advantage of the multitasking capabilities of Simulink Real-Time.
Polling mode is an alternative to the default interrupt mode of the kernel. The kernel on the bootable media created by the UI allows running the real-time application in either mode without using another boot disk.
By default, the real-time application executes in interrupt mode. To switch to polling mode,
you enable polling using a
The following example uses
Open Simulink Real-Time Explorer.
Select the Properties pane for the target computer that you intend to use.
In the Target settings section, check that the Multicore CPU parameter is selected.
In the Configuration Parameters dialog box, on the Simulink
Real-Time Options pane, set Execution mode to
In the Command Window, type:
Build and download the real-time application.
After you have downloaded the real-time application, the target
display shows the execution mode. If you want to execute the real-time application in interrupt mode again, either remove the setting or
0 to the setting:
Rebuild and download the real-time application.
Polling mode runs only on a multicore processor target computer with multicore processing enabled. For more information, see Multicore Processor Configuration.
Polling mode disables interrupts on the core where the base rate task is running. Background tasks and model tasks other than the base rate task are inactive on this core. Tasks for Ethernet communication, target display updates, and UDP transfers run on the other cores. Interrupts are still enabled on cores other than the one running the polling task.