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

Exploring SW Performance 99
of latency, bus loading, memory accesses, arbitration policy, tasks activity.
These parameters allow for exploring SW performance as it can be seen for
the video decoder application presented in the next section.
The first step during the design flow is to create the application tasks in C
language. Next, using VISTA graphical front-end, the applications tasks and
RTOS resources can be allocated on the “black-box”. Preliminary simulation
can now be performed by executing the application code on the virtual
platform to ensure that the code is functionally correct. Then, the code is crosscompiled
on the target processor. VISTA will process the output from the
cross-compilation phase in order to create timing information, which can be
back annotated on the original application code to reflect in situ execution of
the code on the target platform. Finally, timed simulation can be performed
to analyze for system performance and power consumption. The information
extracted from this phase can enable the SW developer to further develop
and refine the application code.
VISTA’s simulator is a compiled C++ program that takes advantage of the
SystemC2.0 kernel, modified so as to get proper debugging and tracing information.
The simulator is launched either as a stand-alone process or as a
dynamic library loaded into the process of the GUI. Ideally both options
should be available as option one is easier to debug and option two is faster.
Several simulation modes are possible. First, interactive simulation: the user
can set graphical input devices on ports of the diagram, like sliders, knobs,
etc. Outputs can be monitored similarly by setting waveform viewers like the
one shown in Figure 8-2, which gathers in one single window the functionality
of an oscilloscope (continuous traces) and of a logic analyzer (discrete
traces). Interactive simulation is essential in the prototyping phases of a
software development. Secondly, batch simulation will also be possible.
2.1. Abstract communication
The accesses are a mechanism to abstract the communication between the
modules and allow a seamless refinement of the communication into the IP
modules from the functional level to the transactional level. SystemC2.0
already provides ports and channels for this purpose. We have enriched the
channel notion with introducing a pattern of three related modules:
2.1.1. Channels models
1.
The slave access first publishes the operations to the channel. It is notified
the channel transactions corresponding to these operation invocations, and
accepts or rejects them. For example, the amba slave access notifies the
amba bus channel whether a transaction is ok, fails or needs to be split.
Note that the publishing mechanism makes that a slave access doesn’t need
to reproduce the slave module interfaces. A slave access can be shared by
several modules, but can only be bound to a single channel.