Design Article
Debugging a Shared Memory Problem in a multi-core design with virtual hardware
Marc Serughetti
5/20/2008 12:20 PM EDT
Over the past few years, the virtual hardware platform concept has emerged as a key new capability for software developers to improve their ability to debug software applications.
Virtual platforms are simulations of the device hardware and the environment it evolves in. They represent a new solution for software developers to improve their productivity. The benefits of virtual platforms for software development come from three major areas.
First, they remove the dependency on the physical silicon availability. Second, they provide a far superior solution for debug and analysis. Third, they provide a simplified and more easily sharable environment to the users.
Traditionally, software developers have used three different types of environments for the execution of the software under development: native compilation to the host development system or an OS simulator, reference development boards, or instruction set simulators. Each of them has been used successfully in the context of a simple hardware platform.
However, as hardware platform capabilities are increasing with multi-core support, these approaches are exhibiting some significant limitations, including limited observability and controllability of the hardware, poor representation of the final device hardware, and limited scalability. This article will demonstrate how a virtual platform can be used to debug a shared memory problem on a multi-core platform.
Platform description
The system under consideration is depicted in Figure 1 below. It includes two
processor cores and several peripheral elements. One core (ARM926) is
used to boot and execute the Linux operating systems and a variety of
applications. The second core (ARM968) is used to execute an H.264
decoding algorithm.
![]() |
| Figure 1: A shared memory design with two processor cores and several peripheral elements, one used to boot and execute the Linux operating system and a variety of applications and the second to execute an H.264 decoding algorithm. |
Peripherals included in the platform include, interrupt controller,
touch screen controller, display controller, ATAPI controller, UART,
programmable I/O, timer, clock and memory.
An AHB multi-layer bus is also used to allow mapping different address regions to the two bus masters. A model of the platform has been created using SystemC a standard hardware modeling language and TLM (Transaction Level Modeling), a standard based modeling methodology.
In addition to the hardware model, the platform comes with host
application programs that enable the interactive I/O user interface in
a realistic device environment.
Each of these applications can directly communicate with the platform model and display the desired information. They include a graphical user interface, connectivity to the host memory file system, and a terminal window showing, for example, the Linux boot sequence.




