[virtual-platform-users:57] Asserting Shared Memory Communication in a Multi-Core System

[AchimNohl]

Hi all,

Here is something that I have presented 2 years back at the MP-Soc
conference. However, I though it fits very well in the recent topics
about using Virtual Prototypes for software testing/ verification. You
can also find it in the whitepaper on the desktop in the cloud.
Moreover, the cloud VP provides an example that you can run by
yourself using Android and an H.264 decoder on a second ARM core (see
at the end of this post).

----
Illegal access to memory can lead to endless debug sessions when we
are getting to the point where we have to integrate multiple software
stacks on a multiple subsystems of a platform communicating via shared
memory. The situation “While bringing up my OS on a platform
subsystem, other parts of the system stopped functioning at some
point.” may sound familiar to those who have dealt with asymmetric
multi processing so called AMP software and Platforms. Here, a domain
refers to an autonomous software stack on a specific Platform
subsystem that may interact with another autonomous software stack on
another Platform subsystem.

Virtual Prototype watchpoints on peripherals or memory regions, which
logically belong to a specific domain, allow catching illegal accesses
from other domains in the system. Here, a watch regions can be tight
to a specific core. E.g. only when core A is accessing a peripheral of
domain B, the system is halted and not if core B is doing the access.
This is a very fundamental characteristic of a Virtual Prototype.
Other than just tracing or asserting accesses to memories, we are able
to assert the initiator of the memory access.

However, once dynamic data structures are used for the exchange of
data via shared memory, static watch regions will not be sufficient.
But the solution scales well to more complex and dynamic shared memory
communication. E.g., we are using a Platform with two subsystems as
shown here:

http://groups.google.com/group/virtual-Platform-users/web/sharedmem_assert1.gif

One subsystem, which is shown in orange, is running a Linux OS with an
H.264 stream driver. The second subsystem, which is shown in blue, is
running an H.264 decoder firmware. The Linux H.264 stream driver sends
the raw video stream to the decoder firmware. The data is exchanged
using a circular buffer data structure that resides in shared memory.
The empty region of the circular buffer, shown in orange, is for the
driver to provide new data. The second region of this buffer, shown in
blue, is for the decoder firmware to read data.

The control and synchronization between the two software stacks is
realized using interrupts and mutex. However, within the control and
synchronization between the two cores, it is not unlikely that hidden
races lead to an illegal access to the circular buffer. This may just
result in an unnecessary trigger of the error correction in the video
decoder. Thus, often those problems are not even recognized during
development as they may not lead to any functional errors, but just
result in a decreased video quality.

Using a Virtual Prototype we have the opportunity to assert illegal
accesses to the circular buffer data structure. As describe earlier,
we have the ability to set a watchpoint on regions that we want to
protect. Meaning, we will have the empty region being protected from a
read access by CPU 2. And we have the data region being protected by a
write access of CPU 0. However, those watchpoint regions do not
remain static. With every read and write they will need to be re-
adjusted. This re-adjustment can be realized using a Virtual Prototype
Debug callback procedure triggered by a watchpoint on the addresses in
shared memory that holds the circular buffer pointers. Whenever those
pointers are changed, the circular buffer watch regions are
automatically re-adjusted. If a CPU is now performing an illegal
access, the execution will be immediately suspended.

See http://groups.google.com/group/virtual-Platform-users/web/sharedmem_assert2.gif

This simple mechanism allows the assertion of complex dynamic
communication in shared memory. It allows us to become aware of
potential problems during development. In contrast to pure software
assertions, the Virtual Prototype scripting allows us to take
advantage of our bird’s eye view and assert the interaction between
multiple software stacks. The described solution can significantly
reduce the risk of having defects being identified late in the
development, or have them even slip into a product.

----

You can try it out yourself in the cloud:
- Launch the Virtual Platform (the highlighted icon)
- Select the Android skin and press F5
- After setup is complete, start booting Android via F5
- Once booted, use the Linux console terminal and type:

cat /media/shrek2.h264 > /dev/amp_comm

- Suspend the simulation via F9
- Launch the assertions and the visualization via
Menu Misc->Observers->H264 Stream Device
- Continue the simulation

BTW: The H.264 decoder is not integrated into the Android SW stack. It
is just writing to the framebuffer. It is sort of ugly, but it was
just migrated from an older integration into this demo.

--
You received this message because you are subscribed to the Google
Groups "Virtual Platform-Users" group.
To unsubscribe from this group, send email to
virtual-platform-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/virtual-platform-users?hl=en