Debugging Capabilities and Tracing of the Problem
The advantage of using a simulated environment such as that shown in Figure 4 below is that the user can have full control of the execution of the hardware. This is, of course, as long as this proper control is offered to him. In this case, we are using the capabilities of a virtual platform debugger, which provide visibility and controllability into any memory element and signals.

In addition, the tool shown in Figure 4 provides a scripting capability (based on tcl) enabling its user to take specific actions when a breakpoint or watch point is hit. For the debugging of our problem, a script that automatically updates the watchpoints after each read and write will be used.

It creates a sandbox where the ARM926 is authorized to write and the ARM968 to read. The script will alert the developer and stop the platform execution when a memory violation occurs (i.e write and read are done outside the sandbox).

In addition, a very visual and intuitive user interface can be created with the script. The picture below provides the structure of the script and the graphical visualization provided by the virtual platform debugger.

Figure 4: Using a simulated environment provides the developer full control of the execution of the hardware.

As we now execute the software using the script, we hit a watchpoint and can start using our software debugging capabilities provided by the Lauterbach debugger (Figure 5, below) to trace the source of the problem:

* First, we locate the function that was called when the memory access occurred.
* Looking at the stack frame, we identify that the read and write pointer are pointing to the same memory location, and a write was performed.
* The function stack enables the identification of the calling function whose source code can now be viewed.

Figure 5. The Lauterbach debugger can be used to trace the source of the memory conflict problems.

We quickly identify that the buffer count has been hard-coded rather than being calculated. The problem is fixed and the re-compiled software is downloaded to the virtual platform showing the proper execution of the software.

Simplifying the Edit-Debug-Compile Cycle
The debugging example provided above demonstrates the key capability of using a virtual platform to accelerate the edit-debug-compile cycle. The virtual platform allowed us to:

1. Identify the problem earlier and without silicon availability
2. Trace its source by allowing a "watch" to be established inside a memory block (not to be confused with CPU watchpoint!) and to dynamically create a "sandbox" to catch buffer overflow errors
3. Solve the problem by quickly pinpointing the source code error for correction, leveraging the integration of existing software development tools such as Lauterbach or gdb
4. Validate the solution through the execution of the updated software.

<>Virtual platform tools provide a powerful solution with fast simulation performance and integration of existing software development tools such as debuggers.

In our specific environment we also have access to a powerful tool acting a virtual platform, which unlocks the unique capabilities of virtual platforms including, controllability and observability of the software and the platform, as well as, a scriptable solution based on a tcl interface.

The integrated solution provides a non-intrusive debugging environment enabling debugging that could not have been efficiently done with physical hardware.

Marc Serughetti is Vice President Marketing & Business Development at CoWare