Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Exploring SW Performance 105
2.2. Timing annotation
Providing timing annotations is a complex task. The camera module example
shows the limited underlying systemc 2.0 mechanisms. Mainly we rely on an
event which is never notified but this event has a timeout to resume the execution.
This is satisfying for the hardware models, not for the software models.
These models shall distinguish active wait from passive wait. The approach
is very similar to SystemC 3.0 direction [8], with the wait and consume functions,
though some other aspects are also taken into consideration which leads
to have several consume-like functions.
The goal is to avoid annotating and recompiling anew the system each time
a new cpu is selected, or each time a cpu frequency changes. Hence the annotation
doesn’t contain a timing, but a timing table index. The table indexes
are the cpu index and the code chunk index. The cpu index is maintained by
the simulation engine.
void consume(int cycle_idx, int ad_idx = 0);
vs_timing_table_t consume(vs_timing_table_t, int cycle_idx,
vs_address_table_t = 0, int ad_idx);
Because of the function inlining, preserving the modularity of the compilation
requires to have a separate consume function that allows to change the
current timing table and thus using the inline function tables. The timing in
the table doesn’t include absolute time, but a number of CPU cycles so that
the elapsed time can be calculated accordingly to the CPU frequency. The last
parameter is for a future version: the idea is to use a code offset to take into
account the effect of an instruction cache. The consume functions shall be
regarded as transaction calls to the operating system which guards the
execution of the code. Consume suspends the execution of the code until the
cycles required to execute this code have been allocated to that particular
segment. Then one have to decide of the good tradeoffs for the simulation
speed and the granularity of the annotations.
3. MPEG VIDEO DECODER CASE STUDY
The MPEG video decoder, illustrated in Figure 8-7, is a application built to
show the way of modeling a system at transaction level with the access
mechanism. Its purpose was to get a hint on how fast a simulation of this level
could, and which details are necessary to build an analysis. The first step
was to design the platform architecture. The edit mode of the tool allows to
draw the hierarchical blocks of the design with their operations. We can either
define new modules or reuse existing ones that are already included into a
component library. Some components are provided with the tool such as the
AMBA AHB bus.