Note: Starting in R2010b, many DSP System Toolbox™ blocks received a new parameter to control whether they perform sample- or frame-based processing. The following content has not been updated to reflect this change. For more information, see the Frame-Based Processing section of the Release Notes.
|On this page…|
The computational delay of a block or subsystem is related to the number of operations involved in executing that block or subsystem. For example, an FFT block operating on a 256-sample input requires Simulink® software to perform a certain number of multiplications for each input frame. The actual amount of time that these operations consume depends heavily on the performance of both the computer hardware and underlying software layers, such as the MATLAB® environment and the operating system. Therefore, computational delay for a particular model can vary from one computer platform to another.
The simulation time represented on a model's status bar, which can be accessed via the Simulink Digital Clock block, does not provide any information about computational delay. For example, according to the Simulink timer, the FFT mentioned above executes instantaneously, with no delay whatsoever. An input to the FFT block at simulation time t=25.0 is processed and output at simulation time t=25.0, regardless of the number of operations performed by the FFT algorithm. The Simulink timer reflects only algorithmic delay, not computational delay.
There are a number of ways to reduce computational delay without actually running the simulation on faster hardware. To begin with, you should familiarize yourself with Manual Performance Optimization in the Simulink documentation, which describes some basic strategies. The following information discusses several options for improving performance.
A first step in improving performance is to analyze your model, and eliminate or simplify elements that are adding excessively to the computational load. Such elements might include scope displays and data logging blocks that you had put in place for debugging purposes and no longer require. In addition to these model-specific adjustments, there are a number of more general steps you can take to improve the performance of any model:
Use frame-based processing wherever possible. It is advantageous for the entire model to be frame based. See Benefits of Frame-Based Processing for more information.
Use the dspstartup file to tailor Simulink for signal processing models, or manually make the adjustments described in Settings in dspstartup.m in the DSP System Toolbox Getting Started Guide.
Turn off the Simulink status bar by deselecting the Status bar option in the View menu. Simulation speed will improve, but the time indicator will not be visible.
This method of starting a simulation can greatly increase the simulation speed, but also has several limitations:
You cannot interact with the simulation (to tune parameters, for instance).
You must press Ctrl+C to stop the simulation, or specify start and stop times.
There are no graphics updates in M-file S-functions, which include blocks such as Vector Scope, etc.
Use Simulink Coder™ code generation software to generate generic real-time (GRT) code targeted to your host platform, and run the model using the generated executable file. See the Simulink Coder documentation for more information.
Algorithmic delay is delay that is intrinsic to the algorithm of a block or subsystem and is independent of CPU speed. In this guide, the algorithmic delay of a block is referred to simply as the block's delay. It is generally expressed in terms of the number of samples by which a block's output lags behind the corresponding input. This delay is directly related to the time elapsed on the Simulink timer during that block's execution.
The algorithmic delay of a particular block may depend on both the block parameter settings and the general Simulink settings. To simplify matters, it is helpful to categorize a block's delay using the following categories:
The following topics explain the different categories of delay, and how the simulation and parameter settings can affect the level of delay that a particular block experiences.
The FFT block is an example of a component that has no algorithmic delay. The Simulink timer does not record any passage of time while the block computes the FFT of the input, and the transformed data is available at the output in the same time step that the input is received. There are many other blocks that have zero algorithmic delay, such as the blocks in the Matrices and Linear Algebra libraries. Each of those blocks processes its input and generates its output in a single time step.
The Normalization block is an example of a block with zero algorithmic delay:
The Normalization Example T1 model opens.
Signal = 1:100
Sample time = 1/4
Samples per frame = 4
The model prepends the current value of the Simulink timer output from the Digital Clock block to each output frame. The Frame Conversion block converts the frame-based signal to a sample-based signal so that the output in the MATLAB Command Window is more easily readable.
The Signal From Workspace block generates a new frame containing four samples once every second (Tfo = π*4). The first few output frames are:
(t=0) [ 1 2 3 4]' (t=1) [ 5 6 7 8]' (t=2) [ 9 10 11 12]' (t=3) [13 14 15 16]' (t=4) [17 18 19 20]'
The normalized output, dsp_examples_yout, is converted to an easier-to-read matrix format. The result, ans, is shown in the following figure:
ans = 0 0.0333 0.0667 0.1000 0.1333 1.0000 0.0287 0.0345 0.0402 0.0460 2.0000 0.0202 0.0224 0.0247 0.0269 3.0000 0.0154 0.0165 0.0177 0.0189 4.0000 0.0124 0.0131 0.0138 0.0146 5.0000 0.0103 0.0108 0.0113 0.0118
The first column of ans is the Simulink time provided by the Digital Clock block. You can see that the squared 2-norm of the first input,
[1 2 3 4]' ./ sum([1 2 3 4]'.^2)
appears in the first row of the output (at time t=0), the same time step that the input was received by the block. This indicates that the Normalization block has zero algorithmic delay.
When several blocks with zero algorithmic delay are connected in a feedback loop, Simulink may report an algebraic loop error and performance may generally suffer. You can prevent algebraic loops by injecting at least one sample of delay into a feedback loop , for example, by including a Delay block with Delay > 0. For more information, see Algebraic Loops in the Simulink documentation.
The Variable Integer Delay block is an example of a block with algorithmic delay. In the following example, you use this block to demonstrate this concept:
The Variable Integer Delay Example T1 opens.
Signal = 1:100
Sample time = 1
Samples per frame = 1
Constant value = 3
Interpret vector parameters as 1–D = Clear this check box
Sampling mode = Sample based
Sample time = 1
Click OK to save these parameters and close the dialog box.
The input to the Delay port of the Variable Integer Delay block specifies the number of sample periods that should elapse before an input to the In port is released to the output. This value represents the block's algorithmic delay. In this example, since the input to the Delay port is 3, and the sample period at the In and Delay ports is 1, then the sample that arrives at the block's In port at time t=0 is released to the output at time t=3.
The model should look similar to the following figure.
The output is shown below:
dsp_examples_yout = 0 -1 1 -1 2 -1 3 1 4 2 5 3
The first column is the Simulink time provided by the Digital Clock block. The second column is the delayed input. As expected, the input to the block at t=0 is delayed three samples and appears as the fourth output sample, at t=3. You can also see that the first three outputs from the Variable Integer Delay block inherit the value of the block's Initial conditions parameter, -1. This period of time, from the start of the simulation until the first input is propagated to the output, is sometimes called the initial delay of the block.
Many DSP System Toolbox blocks have some degree of fixed or adjustable algorithmic delay. These include any blocks whose algorithms rely on delay or storage elements, such as filters or buffers. Often, but not always, such blocks provide an Initial conditions parameter that allows you to specify the output values generated by the block during the initial delay. In other cases, the initial conditions are internally set to 0.
Consult the block reference pages for the delay characteristics of specific DSP System Toolbox blocks.
Under certain conditions, Simulink may force a block to delay inputs longer than is strictly required by the block's algorithm. This excess algorithmic delay is called tasking latency, because it arises from synchronization requirements of the Simulink tasking mode. A block's overall algorithmic delay is the sum of its basic delay and tasking latency.
Algorithmic delay = Basic algorithmic delay + Tasking latency
The tasking latency for a particular block may be dependent on the following block and model characteristics:
Simulink has two tasking modes:
To select a mode, from the Simulation menu, select Model Configuration Parameters. In the Select pane, click Solver. From the Type list, select Fixed-step. From the Tasking mode for periodic sample times list, choose SingleTasking or MultiTasking. If, from the Tasking mode for periodic sample times list you select Auto, the simulation runs in single-tasking mode if the model is single-rate, or multitasking mode if the model is multirate.
Note: Many multirate blocks have reduced latency in the Simulink single-tasking mode. Check the "Latency" section of a multirate block's reference page for details. Also see Scheduling in the Simulink Coder User's Guide.
A block is called single-rate when all of its input and output ports operate at the same frame rate. A block is called multirate when at least one input or output port has a different frame rate than the others.
Many blocks are permanently single-rate. This means that all input and output ports always have the same frame rate. For other blocks, the block parameter settings determine whether the block is single-rate or multirate. Only multirate blocks are subject to tasking latency.
Note: Simulink may report an algebraic loop error if it detects a feedback loop composed entirely of multirate blocks. To break such an algebraic loop, insert a single-rate block with nonzero delay, such as a Unit Delay block. See the Simulink documentation for more information about Algebraic Loops.
When all ports of all blocks in a model operate at a single frame rate, the model is called single-rate. When the model contains blocks with differing frame rates, or at least one multirate block, the model is called multirate. Note that Simulink prevents a single-rate model from running in multitasking mode by generating an error.
Many blocks can operate in either sample-based or frame-based modes. In source blocks, the mode is usually determined by the Samples per frame parameter. If, for the Samples per frame parameter, you enter 1, the block operates in sample-based mode. If you enter a value greater than 1, the block operates in frame-based mode. In nonsource blocks, the sample mode is determined by the input signal. See the block reference pages for additional information about specific blocks.
The specific amount of tasking latency created by a particular combination of block parameter and simulation settings is discussed in the "Latency" section of a block's reference page. In this topic, you use the Upsample block's reference page to predict the tasking latency of a model:
The Upsample Example T1 model opens.
Most multirate blocks experience tasking latency only in the Simulink multitasking mode.
Signal = 1:100
Sample time = 1/4
Samples per frame = 4
Form output after final data value by = Setting to zero
Upsample factor, L = 4
Sample offset (0 to L-1) = 0
Input processing = Columns as channels (frame based)
Rate options = Allow multirate processing
Initial condition = -1
The Rate options parameter makes the model multirate, since the input and output frame rates will not be equal.
This matches the sample period of the Upsample block's output.
The model should now look similar to the following figure.
The model prepends the current value of the Simulink timer, from the Digital Clock block, to each output frame. The Frame Conversion block converts the frame-based signal into a sample-based signal so that the output in the MATLAB Command Window is easily readable.
In the example, the Signal From Workspace block generates a new frame containing four samples once every second (Tfo = π*4). The first few output frames are:
(t=0) [ 1 2 3 4] (t=1) [ 5 6 7 8] (t=2) [ 9 10 11 12] (t=3) [13 14 15 16] (t=4) [17 18 19 20]
The Upsample block upsamples the input by a factor of 4, inserting three zeros between each input sample. The change in rates is confirmed by the Probe blocks in the model, which show a decrease in the frame period from Tfi = 1 to Tfo = 0.25.
The output from the simulation is displayed in a matrix format. The first few samples of the result, ans, are:
"Latency and Initial Conditions" in the Upsample block's reference page indicates that when Simulink is in multitasking mode, the first sample of the block's frame-based input appears in the output as sample MiL+D+1, where Mi is the input frame size, L is the Upsample factor, and D is the Sample offset. This formula predicts that the first input in this example should appear as output sample 17 (that is, 4*4+0+1).
The first column of the output is the Simulink time provided by the Digital Clock block. The four values to the right of each time are the values in the output frame at that time. You can see that the first sample in each of the first four output frames inherits the value of the Upsample block's Initial conditions parameter. As a result of the tasking latency, the first input value appears as the first sample of the 5th output frame (at t=1). This is sample 17.
Now try running the model in single-tasking mode.
The model now runs in single-tasking mode.
The first few samples of the result, ans, are:
"Latency and Initial Conditions" in the Upsample block's reference page indicates that the block has zero latency for all multirate operations in the Simulink single-tasking mode.
The first column of the output is the Simulink time provided by the Digital Clock block. The four values to the right of each time are the values in the output frame at that time. The first input value appears as the first sample of the first output frame (at t=0). This is the expected behavior for the zero-latency condition. For the particular parameter settings used in this example, running upsample_tut1 in single-tasking mode eliminates the 17-sample delay that is present when you run the model in multitasking mode.
You have now successfully used the Upsample block's reference page to predict the tasking latency of a model.