Target Support Package™ IC1

Real-Time Workshop Options for Execution Profiling

Execution Profiling

You can see the options for execution profiling by selecting C166 Options (1) (under Real-Time Workshop in the tree) in the Configuration Parameters dialog box.

If the Execution Profiling option is selected, then the generated code for the model will be "instrumented" with function calls at the beginning and end of each task or ISR to be profiled. These function calls read a timer (on C166 a free running timer is selected from the options in the C166 Resource Configuration block) and log this reading along with a task identifier.

When code for the model is generated, these functions will update data on the worst-case turnaround time for each timer-based task as well as the worst-case number of concurrent task overruns, whenever a previous worst-case value is exceeded. Additionally, when a trigger is provided, data will be logged over a period of time to record all task start and finish times. The trigger signal can be supplied, for example, by the block C166 Execution Profiling via CAN A.

Back to Top

Number of Data Points

When a snapshot of task and ISR activity is logged, this data is stored in memory that is statically allocated at build time. Each data point requires 4 bytes on C166. The larger the number of data points to be stored, the more RAM that must be reserved for this purpose. At the end of a logging run, the data must be uploaded to the host computer for analysis; this is typically achieved by using one of the C166 execution profiling blocks — via ASCO, CAN A, or TwinCAN A. See the reference pages for C166 Execution Profiling via ASC0, C166 Execution Profiling via CAN A, and C166 Execution Profiling via TwinCAN A.

Back to Top

Task Scheduler Overrun Options

These scheduler options configure the allowable number of concurrent task overruns. You can see these options on the C166 Options (1) section in the Configuration Parameters dialog box.

You can use the options Maximum number of concurrent base-rate overruns and Maximum number of concurrent sub-rate overruns to configure the behavior of the scheduler when any of the timer based tasks do not complete within their allowed sample time. It is useful to allow task overruns in the case where a task may occasionally take longer than usual to complete (e.g., if extra processing is required when a special event occurs); if the task overrun is only occasional, then it is possible for the scheduler to catch up after the extra processing has been completed.

If the maximum number of concurrent overruns for any task is exceeded, this is deemed to be a failure and the real-time application is stopped.

As an example, if the base rate is 1 ms and the maximum number of concurrent base-rate overruns is set to 5 then it is possible for the base rate task to run for almost 6 ms before failure occurs. Once the overrun has occurred, it is necessary for subsequent executions of the base rate to complete in less than 1 ms in order that the lost time is recovered.

The occurrence of base-rate overruns does not affect the numerical behavior of the algorithm (although reading/writing external devices will of course be delayed).

If sub-rate overruns are allowed, then the transfer of data between different rates (via rate-transition blocks) in the model may be affected; this causes the numerical behavior in real time to differ from the behavior in simulation. To see an illustration of this effect, try running the demo model c166_multitasking, described in the next section. To disallow sub-rate overruns and ensure that this effect does not occur, you should set Maximum number of concurrent sub-rate overruns to zero.

Note   Allowing sub-rate overruns may cause non-determinism and loss of integrity for data transferred between different rates in the model. Set this value to zero if you require sub-rate overruns to be handled as a failure (recommended).

If you allow sub-rate overruns, then the behavior of any Rate-Transition blocks may be affected. Specifically, if the model contains a Rate Transition block where the option "Ensure deterministic data transfer (maximum delay)" is selected, then this setting may not be honored.

Back to Top

Overview of Execution Profiling

Multitasking Demo Model