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.