Earlier in Part 1, we described the benefits of leveraging virtual platforms to validate architecture, performance and embedded software. In this second part, a case study is provided as a means to illustrate the concepts and benefits of using a well-modeled virtual platform of a simple system-on-chip (SoC) design.

The article will discuss how to effectively use interface and abstraction techniques, modeling tools, debugging techniques, and profiling to characterize and validate architectures and embedded software.

Components of a Virtual Platform
Many different methods are used to create virtual platforms, ranging from ad-hoc approaches to commercially available tools and platforms. Regardless of the approach taken, in order to construct a virtual platform, four critical components are required: models, a simulation engine, software, and analysis tools.

The backbone of any virtual prototype is the components that model the functionality of the system and interconnect. Models of the embedded processor, cache subsystem, memory subsystem, and bus-level interconnectivity are typical in almost every SoC-based system.

In addition, direct memory access (DMA) engines, hardware accelerator cores, peripherals, and controllers are usually required to complete the functionality of the prototype.

These models can vary in abstraction from high-level behavioral models to implementation-accurate models depending on the level of accuracy needed for analysis and the performance required for software execution. At a minimum, each piece of the SoC in a virtual prototype must have some level of representation in order to run the embedded software.

By themselves, models are not useful unless they can be called and executed in the proper order and communicate with one another. A simulation engine is required to provide a calling mechanism, order events and time, and provide the channels of communication between the models. Simulation engines typically accommodate executing various abstraction levels of models.

In addition, the simulation engine and models need to provide a mechanism to communicate with the outside world. Traffic generators and input and output devices need to be emulated to provide stimulus to the virtual platform.

No virtual prototype is complete without the software that runs on the embedded processors. This software can range from low-level firmware to drivers and operating systems to high-level application code. The software might be the target of validation by a software engineer or it might be used by the architect to validate the performance within the system.

The virtual prototype must provide the mechanisms to compile, link, and load the software into the memory subsystem modeled in the virtual prototype.

Once all of the hardware and software pieces of a virtual prototype are assembled, tools are required to debug and analyze the execution of the system. These tools include software debuggers, hardware and software profilers, and signal/waveform tools to analyze the temporal activity in the system.

Bringing Hardware and Software Together
A case study of a simple virtual platform illustrates how a virtual prototype can be quickly assembled and used to analyze and characterize interactions between the hardware and software in a system.

The SoC Designer platform will be used to provide the simulation engine and communication channels between models. Its semi-hosting capabilities will provide the mechanism to emulate input and output devices and its profiling and debugging tools will be used to illustrate how to profile and debug both the hardware and software in a running system.

The SoC used in the case study is a simple system comprised of an ARM Cortex processor, an AXI and AHB bus subsystem, a simple memory subsystem, and a timer and interrupt controller peripherals. Below in Figure 1 below is a schematic view of the platform.

Figure 1. Schematic view of ARM/Cortex platform

This platform illustrates a mixture of abstraction levels. The Cortex processor model is cycle accurate while the Vectored Interrupt Controller (VIC) is an implementation-accurate model compiled directly from Verilog register transfer level (RTL) code.

All other models are behavioral models written in C++. Notice that the semihost block, which allows the input and output control for the simulation. Transaction level communication is illustrated above with the thick connections between modules (AXI, AHB, and APB interfaces) while signal level interfaces are shown with the thin connections (interrupts) and the implied connections (clocks).

This case study uses a simple sort program for the software application running on the ARM processor. The software targeted for the Cortex processor is written in C code and compiled and linked with the ARM RealView software development tools.

When the simulation starts, the platform asks what program should be loaded into the memory subsystem. The platform also understands how each block is memory mapped to its respective bus. The processor then can load the program at the proper address range into the appropriate memory region (the RAM model in the above diagram).

Virtual Platform Execution
After the hardware and software has been represented appropriately in the virtual platform, execution is easily initiated and controlled. For this case study, SoC Designer provides the option of continuous running or cycle stepping of the execution.

Figure 2. Console window with 99 string sorting request

Breakpoints can be set to stop simulation on any event in the system, such as register changes in the models or signal or transaction changes in the interconnect.

Early on in the execution, the software asks the user to input the number of strings to sort. The platform uses semi-hosting to emulate the stdout functions to the console and the stdin for the user's input. Shown above in Figure 2 is the console input requesting the number of stings to sort.

Figure 3. Output based on request submitted in Figure 2.

After the software has read the users input, the sorting algorithm is performed using 99 strings in this case. The program running on the processor outputs the status to stdout, emulated again as shown below in Figure 3 above.

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.