Analysis of the Virtual Platform
Virtual platforms provide a rich set of debug and analysis capabilities unavailable in real systems allowing the user to set both hardware and software breakpoints at any time during the system simulation.

Compared to real hardware and hardware prototypes, the visibility of the interconnect and model registers available in a virtual prototype far surpass what is available in hardware approaches. Furthermore, the ability to start and stop execution at any time provides fine-grained control in a virtual prototype that can't be reproduced in real hardware.

To illustrate this, a breakpoint is set for an internal change of the VIC's Interrupt Enable register and the interrupt signal connecting the interrupt controller to the processor. The red dots show the breakpoints that have been set in Figure 4 below.

Figure 4. Breakpoints set for internal change of Interrupt Enable register

In this case, these two breakpoints allow the user to see how interrupts are programmed and handled by the software running in the processor. The Realview debugger will be used to see the source code at these two hardware breakpoints.

As the simulation is rerun, the first breakpoint - VICIRQEnable register inside the VIC - shows the code executing in the processor when it is setting up interrupts.

static void initializeVIC(void) {
*vicIntSel = 0; // Select IRQ for all interrupts
*vicIntEna = 0x00000002; // Enable the second interrupt line
}

The second breakpoint - on the irq signal between the VIC and processor - takes the user to the code that has been developed to handle interrupts.

_irq void IRQ_Service(void){
switchSorter = true; // Switch the sort routine
*timer_clear = 1; // clear the timer interrupt
}

Just as the virtual platform can be stepped cycle by cycle, the debugger can be single stepped and software breakpoints can be added to control execution. This shows another capability of a virtual platform: controlling execution from both the software and hardware domains.

This is a simple example, but it shows the benefit of setting internal hardware breakpoints to provide productivity boosts to debug and analyze software that manipulates the hardware.

Imagine how this technique could be used to debug some complex hardware and software interaction causing unanticipated behavior in the hardware that may have be due to poorly written software.

Conversely, imagine a subtle bug in the hardware causing unexpected behavior in the software. A virtual platform provides both the control and visibility to attack the problem from both sides. In addition, waveforms and traces can be dumped to provide hardware engineers valuable temporal data to understand the hardware behavior during software execution.

Debugging is only one aspect of the analysis that can be performed with a virtual prototype. Profiling software and hardware interactions together is another key aspect of a virtual platform.

This case study profiled how much time software takes to execute its interrupt routine simultaneously with profiling the actual hardware interrupts in the system.

Figure 5 below shows a software profile of the software running on the processor (top pane) together with the profile of interrupts processed in the vectored interrupt controller (bottom pane).

Figure 5. Software profile of the software running on the processor (top pane) and the profile of interrupts processed in the vectored interrupt controller (bottom pane).

It's easy to understand cause and effect behavior of interrupts being processed in the VIC and associated routines that get called in response to the processor receiving an interrupt. In this case, the processor was executing a routine called _sputc when the interrupt occurred (orange in the bottom pane).

The processor jumped to the IRQ_Handler via the exception vectoring code . After the IRQ_Handler finished servicing the interrupt, it cleared the interrupting source inside the timer which caused the interrupt signal to clear inside the VIC.

Again, this is a simple example, but the same techniques could be used to profile more complex issues - cache behavior of software routines or analysis of the performance of different bus and memory architectures, for example.

Using profiling techniques such as these have been shown to improve software performance [1] by providing a clear understanding of precise hardware/software interaction and identifying places to optimize code execution. These techniques can also be used to find hardware issues that cause software to under perform, including arbitration schemes, pipeline effects and caching.

Conclusion
Virtual platforms provide powerful capabilities in the validation, debug, and analysis of SoC systems. Their controllability and visibility provide invaluable productivity to the architect, system developer, and software engineer that are unsurpassed when compared to other types of prototypes.

Problems that might take days to unravel on a real system can be debugged in a few minutes to hours on a virtual prototype. For architecture validation and performance analysis a virtual prototype provides the detailed views to truly understand interaction of hardware and software within the system scope.

Andy Ladd is Vice President Applications and Methodology at Carbon Design Systems in Acton, Mass. He can be reached at andy@carbondesignsystems.com

References
[1] Hong, Sungpack et al., "Creation and Utilization of a Virtual Platform for Embedded Software Optimization: An Industrial Case Study," Proceeding of the 4th international conference on hardware/software co-design and system synthesis: October 2006.