When you run your code on-target, or on-host using a simulator, RapiTime collects several timing metrics. These include worst-case execution time, high and low water mark paths, and minimum, average and maximum execution times for each test of your code.
This page lists several frequently asked questions for RapiTime, the on-target timing analysis verification tool.
RapiTime is part of the RVS product range. For frequently asked questions on RVS tools in general, click here.
The worst-case execution time reported by RapiTime is pessimistic, meaning the actual worst-case execution time of your code could not be higher than that reported by RapiTime. This satisfies the stringent requirements of embedded system certification.
RapiTime includes inbuilt functionality to let you determine the execution time overhead of adding instrumentation to your source code. This overhead can then be automatically subtracted from the timing metrics reported by the tool.
As with all RVS tools, RapiTime supports collection of timing data on multi-core architectures. RapiTime achieves this by suspending data collection during a task interrupt and reinitializing collection when the task on the current core resumes execution. You can also use RapiTime to identify the interference produced by other cores on your system under test.
The instrumentation overheads for RapiTime tools are very low, and zero-instrumentation overhead can even be supported in some cases, depending on your target hardware and data collection strategy. This means that you can use RapiTime with virtually any target.
You can use timing metrics to optimize your code for timing behavior. RapiTime highlights the costliest functions in terms of execution time, guiding you towards the best optimization candidates. By running RapiTime again after you optimize your code, you can determine performance improvements.