Absolute and Elapsed Time Computation

About Timers

Certain blocks require the value of either absolute time (that is, the time from the start of program execution to the present time) or elapsed time (for example, the time elapsed between two trigger events). Targets that support the real-time model (rtModel) data structure provide efficient time computation services to blocks that request absolute or elapsed time. Absolute and elapsed timer features include

Timers are implemented as unsigned integers in generated code.
In multirate models, at most one timer is allocated per rate. If no blocks executing at a given rate require a timer, a timer is not allocated to that rate. This minimizes memory allocated for timers and significantly reduces overhead involved in maintaining timers.
Allocation of elapsed time counters for use of blocks within triggered subsystems is minimized, further reducing memory usage and overhead.
S-function and TLC APIs let your S-functions access timers, in simulation and code generation.
The word size of the timers is determined by a user-specified maximum counter value that you set with model configuration parameter Application lifespan (days). If you specify this value, timers do not overflow. For more information, see Control Memory Allocation for Time Counters.

See Absolute Time Limitations for more information about absolute time and the restrictions that it imposes.

Timers for Periodic and Asynchronous Tasks

Timing services provided for blocks execute within periodic tasks (that is, tasks running at the model base rate or subrates).

The code generator also provides timer support for blocks whose execution is asynchronous with respect to the periodic timing source of the model. See the following topics:

Allocation of Timers

If you create or maintain an S-Function block that requires absolute or elapsed time data, it must register the requirement (see Access Timers Programmatically). In multirate models, timers are allocated on a per-rate basis. For example, consider a model structured as follows:

There are three rates, A, B, and C, in the model.
No blocks running at rate B require absolute or elapsed time.
Two blocks running at rate C register a requirement for absolute time.
One block running at rate A registers a requirement for absolute time.

In this case, two timers are generated, running at rates A and C respectively. The timing engine updates the timers as the tasks associated with rates A and C execute. Blocks executing at rates A and C obtain time data from the timers associated with rates A and C.

Integer Timers in Generated Code

In the generated code, timers for absolute and elapsed time are implemented as unsigned integers. The default size is 64 bits. This is the amount of memory allocated for a timer if you set model configuration parameter Application lifespan (days) to inf. For an application with a sample rate of 1000 MHz, a 64-bit counter will not overflow for more than 500 years. See Timers in Asynchronous Tasks and Control Memory Allocation for Time Counters for more information.

Elapsed Time Counters in Triggered Subsystems

Some blocks, such as the Discrete-Time Integrator block, perform computations requiring the elapsed time (delta T) since the previous block execution. Blocks requiring elapsed time data must register the requirement (see Access Timers Programmatically). A triggered subsystem then allocates and maintains a single elapsed time counter if required. This timer functions at the subsystem level, not at the individual block level. The timer is generated if the triggered subsystem (or a unconditionally executed subsystem within the triggered subsystem) contains one or more blocks requiring elapsed time data.

Note

If you are using simplified initialization mode, elapsed time is reset on first execution after becoming enabled, whether or not the subsystem is configured to reset on enable. For more information, see Underspecified initialization detection.