Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Controls/MCUs

Debugging a shared memory problem in multicore with virtual hardware

Posted: 08 Jul 2008 ?? ?Print Version ?Bookmark and Share

Keywords:debugging shared memory? multicore debugging? virtual hardware?

Marc Serughetti

With multicore systems becoming the norm, software developers have found the debugging of such systems, using a physical hardware development board, to be very challenging, particularly when it comes to the integration of applications sharing data across multiple cores.

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 multicore 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. It includes two processor cores and several peripheral elements. One core (ARM926) is used to boot and execute the Linux OS 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 OS and other applications and the second to execute an H.264 decoding algorithm.

Peripherals included in the platform include, interrupt controller, touchscreen controller, display controller, ATAPI controller, UART, programmable I/O, timer, clock and memory.

An AHB multilayer 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.

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 multicore 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 OS 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 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.

1???2?Next Page?Last Page

Article Comments - Debugging a shared memory problem in...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top