Software development environment
The software development environment provided to the software developer contains:

* The simulation of the hardware platform on which the software can be downloaded and executed
* A virtual platform debugger" unlike most software debuggers that only examine the state of the processor, a virtual platform debugger can set breakpoints and watchpoints on every memory element and signal of the entire platform.
* Integration with source code-level debugging software development tools such as gdb and Lauterbach.

Figure 2 below provides an overview of this environment for multi-core debugging, providing a non-intrusive, deterministic and fully controllable development environment.

The virtual platform simulation performances are such that a few seconds are needed to simulate the operating system boot and the movie stream is executed at a speed near or faster than real-time. These performances demonstrate that SystemC, a C++ based language perfectly scales to the performance requirements of software developers.

Figure 2: Use of a virtual platform multicore debugging environment can be used to resolve possible shared memory problems illustrated in Figure 1.

As the initial version of our software is compiled and downloaded to the virtual platform, we quickly observe through our user interface that the video stream being displayed only goes for a small period of time and appears to skip significant sections of the movie being decoded.

Using the Lauterbach software debugger and gdb each connected to an ARM processor, we can quickly identify that each core is alive, leaving the potential problem to the H.264 algorithm or the use of the shared memory between the two processors. Since this decoder previously worked properly on a single processor core architecture, we suspect that the problem is in the use of the shared memory.

Shared memory architecture
A circular buffer (Figure 3 below) is being used in this architecture. The ARM926 reading the video file passes the data to the ARM968 where the video stream is decoded and sent to the display device. The circular buffer presents another challenge for the software developer.

At any point in time, the ARM926 can write on a portion of the buffer and the ARM968 can read from another portion. If the ARM926 were to write in the wrong portion, then it would overwrite data that the ARM968 had not yet read, and accordingly, would have the effect of skipping part of the movie being decoded. A valid and an invalid access to the circular buffer is depicted below.

Figure 3: Valid and an invalid access to the circular buffer

The challenge facing the software developer is that the watchpoints have to be changed after every read or write since the memory area keeps changing. In addition, watchpoints need to be placed on the circular buffer itself to gain the right visibility in the behavior.