Considerations about the WCET
Last updated
Last updated
Evaluating the task’s execution time.
Can be made via source code analysis, to determine the longest execution path, according with the input data.
Then the corresponding object code is analyzed to determine the required number of CPU cycles.
Note that the execution time of a task may vary from instance to instance, according with the input data or internal state, due to presence of conditionals and cycles, etc.
It is also possible execute tasks in isolation and in a controlled fashion, feeding them with adequate input data and measuring its execution time on the target platform.
This experimental method requires extreme care to make sure that the longest execution paths are reached, a necessary condition to obtain an upper bound on the execution time!
Modern processors use features like pipelines and caches (data and/or instructions) that improve dramatically the average execution time but that present an increased gap between the average and the worst-case scenarios.
For these cases are used specific analysis that try to reduce the pessimism, e.g. by bounding the maximum number of cache misses and pipeline flushes, according with the particular instruction sequences.
Nowadays there is an growing interest on stochastic analysis of the execution times and respective impact in terms of interference.
The basic idea consists in determining the distribution of the probability of the execution times and use an estimate that covers a given target (e.g. 99% of the instances).
In many cases (mainly when the worst case is infrequent and much worst than the average case) this technique allows reducing drastically the impact of the gap between the average execution time and the WCET (higher efficiency).