Virtual prototyping pushes the fast forward button for software development

Developing software for hardware prototypes that aren’t yet available has always been a complex, time-consuming task with inherent risk. The arrival of effective, easy-to-use development tools was a significant first step toward developing code faster with fewer bugs. Next, JTAG and other hardware debug interfaces ushered in an era where hardware systems began to be built with effective software development and analysis in mind. These two steps made things easier on the software developer, who nonetheless continued to face the “serial development” conundrum: At the very least hardware prototypes must be available in order to begin software validation. Often problems with the hardware prototype are only found during the first iterations of the software development – a hobgoblin that eats up time as hardware gets updated and even leads to major software rewrites and schedule delays.

This month we’ll investigate virtual prototyping – the leveraging a collection of hardware component simulation models to write and test system and application software. To understand how virtual prototyping promises to dramatically reduce development time and costs, consider a scenario where a software developer can identify bugs or sub-optimal hardware features at the same time the hardware is being developed. The software and hardware interaction enabled at this stage of the development can save significant time and money before a chip has so much as touched a circuit board.

I recently spoke with Marc Serughetti, Director of Marketing at Synopsys, and a pioneer in the area of virtualization technologies. He shared a number of interesting insights about the Virtual Prototype concept.

What is a Virtual Prototype?

A Virtual Prototype is a fast simulation of the hardware that enables hardware and software integration and testing without the physical hardware. Ideally, the prototype also includes compatibility with traditional hardware interface and software development tools along with control and analysis tools that take advantage of new Virtual Prototype environment features.

Figure 1 shows the architecture of a Virtual Prototype.

The lowest level blocks house the simulation environment. This is typically some kind of readily available PC or workstation running Windows or Linux operating systems.

Above this layer is the simulation environment framework, which houses the simulation models available. The framework provides interfaces to various development tools and physical hardware interfaces that might also be available on the workstation, so serial I/O or graphics screens, for example, can be hooked to the simulation to validate the actual I/O results.

Working with model simulations that enable specialized simulation tools that can control and analyze what’s going on with the hardware and the software during execution makes complex interactions easy to analyze. We’ll discuss the unique properties of these simulations later in this article.

Another convenient feature of this environment is that the same executable binary developed within the simulation environment will actually run on the physical hardware when it’s available.

An openly available, educational, Synopsys Virtual Prototype of the ARM Realview Baseboard provides two launch configurations (or skins):

1.   The “vanilla” Linux skin for exploring the booting and operation of Linux on a Virtual Prototype. This skin serves as a starting point for Linux-based driver, middleware, and application development.

2.   The Android skin runs the full Android 2.0 software stack for mobile devices based on the open handset alliance. Android Java applications run on the Linux-based Dalvik Virtual Machine (DVM). While this particular skin isn’t necessarily related to blade development, the concepts and components available in the simulation environment certainly are.

This Virtual Prototype software development environment can serve a number of purposes. First, is the ability to develop device drivers for particular components that may be on the circuit board. At this level, all you really need is the vanilla Linux skin and the simulation component for the device, in order for the driver to be written and tested. Second, once the Virtual Prototype simulation components and driver software has been written, the Virtual Prototype can be used to develop applications with the ability to interface with the real I/O and other blades that may be connected to the backplane of the system. For example, consider the efficiency of using a standard CompactPCI, AdvancedTCA, or MicroTCA Pentium blade running Windows to simulate a new I/O blade. Now the communication between that new blade and other existing blades and switch fabric can be developed, validated, and benchmarked – all using an off-the-shelf blade with a simulation environment that accurately models the components that will be on the new blade.

At the operating system level, the simulation environment enables debug and analysis of processes, threads, memory access, and caching activity. These capabilities are fully scriptable to allow custom debug monitors and the creation of test harnesses.

Traditional and well-known source code software debuggers can be used with a Virtual Prototype. In addition multiple debuggers, including the GNU debugger (GDB), ARM RealView, Lauterbach, and the Android Eclipse SDK for application debugging, can be used in a synchronized manner under the control of the Virtual Prototype simulation.

Your first interface to the Virtual Prototype environment is the Synopsys Virtual Prototype (VP) manager. The VP manager allows you to select a skin and launch a simulation configuration. The Virtual Prototype analyzer is started on launch. This is the “cockpit” where the VP analyzer software debuggers can be launched for each processor core and analysis of the collected data.

Synopsys has a demonstration environment that can be accessed locally that I highly recommend you try out. Once you’ve gotten your access through the Virtual Prototype manager and have signed up for access, then configured your virtual environment with some of the standard simulation components available in the Virtual Prototype, you’ll be emailed access instructions and a link to your demo machine. A java applet is started and the Virtual Prototype’s desktop appears containing a button to launch the Virtual Prototype. PDF docs, links to the Virtual Prototype user group and the Synopsys Web site along with a Powerpoint presentation and white paper are available through the VP manager. The Virtual Prototype analyzer is started, the simulation is launched, and you’re ready to explore the Virtual Prototype.

Standards enabling virtual prototypes

We’ve talked a lot about “simulation components” in the abstract, but haven’t really discussed what they are. There are some new silicon/hardware component modeling standards that are key enablers to the Virtual Prototype concept – SystemC and Transaction-Level Modeling (TLM). SystemC and TLM define structure and methodologies that are used to simulate a hardware system at a higher level of abstraction. Open SystemC Initiative (OSCI) is the organization that controls this, and these methodologies (www.systemc.org) have led to the release of IEEE 1666, which is the governing standard for these simulation and modeling standards.

Problems solved by the Virtual Prototype concept

Marc Serughetti states that the idea of the Virtual Prototype is to leverage the models created by the hardware developers to create a comprehensive software simulation environment that can, in turn, be used for system and application software development.

“How the Virtual Prototype is used depends on the objective of the end-user,” Marc mentions. “At the most complete level, you take all these models and put them into one big system. But an iterative approach can be better and more efficient – a subset of the simulation environment will enable software developers to get sub-components done. Or perhaps the software developer only needs the register map for the peripheral and can complete their software tasks just by having a single peripheral model.”

At its essence, the concept of Virtual Prototypes is simple – when a developer does not have the physical hardware, he can replace it with a Virtual Prototype to accomplish some number of software design and development tasks without needing access to the final hardware.

In a situation where the hardware has not been developed yet, the Virtual Prototype has obvious benefits. Another perhaps more applicable scenario for larger CompactPCI or AdvancedTCA systems is that when it costs too much for individual software developers to have their own systems for development end debugging, the Virtual Prototype offers a lower cost solution. And one that maximizes parallel software development without any guesswork on the software developer’s part.

Visibility, control, and more

When it comes to validation of the software within the simulation environment, software developers want to test from perspectives such as visibility and control. Testing from this angle focuses on functional correctness as it pertains to the operation of the software on the hardware prototype.

For multicore development, such validation can be challenging to perform on the actual hardware, so the Virtual Prototype can actually be a preferred method for accomplishing this testing. For example, standard hardware debuggers hook to multicore boards, and breakpoints can be set. But one limitation of the hardware environment is that when the breakpoint is hit on one of the cores, the other cores continue to execute. So when the breakpoint is hit and the developer begins poking around registers and interfaces, other software on other cores may have over-written or changed critical information needed at the point of the break.

The Virtual Prototype, on the other hand, can stop all the simulated components at the exact moment of the breakpoint. Now the developer can poke around not only on the core where the breakpoint was hit, but also on the other cores and external simulated components, discovering probable important clues as to what’s going on with the execution of the software.

Virtual Prototypes can be modeled at multiple levels of abstraction. Each abstraction level has its own modeling style:

·    Untimed – A modeling style with no explicit mention of time or cycles but which includes concurrency and sequencing of operations.

·    Loosely timed – A modeling style that represents minimal timing information sufficient only to support features necessary to boot an operating system and to manage multiple threads in the absence of explicit synchronization between those threads.

·    Approximately timed – A modeling style with one-to-one mapping between the externally observable states of the model and the states of some corresponding detailed reference model, such that the mapping preserves the sequence of state transitions but not their precise timing.

·    Cycle accurate – A modeling style in which it is possible to predict the state of the model in any given cycle at the external boundary of the model and thus to establish a one-to-one correspondence between the states of the model and the externally observable states of a corresponding RTL model in each cycle.

Depending on the end task, users may select the appropriate abstraction level. For most software development activities, the most common abstraction level will be loosely timed.

More accurate abstraction levels are ultimately penalized with slower simulation performance and so affect developer productivity.

Marc mentions that the example Virtual Prototype Synopsys offers is modeled with the loosely timed modeling style and includes an ARM9 processor that can plug into a PC along with the tools and simulation components. The example typically serves as a “for instance” introduction to the environment. Synopsys creates and provides some simulation models, but the real strength of the Virtual Prototype concept is that users can configure a system based on standard simulation components that have been created by any silicon development team.

And of course, since the simulation environment is based on the hardware simulation models for ARM, PowerPC, MIPS, or other processors, the simulation is agnostic to the language itself. The software is written, compiled into the executable for the target, and the compiled executable for the hardware target will run the native assembly for the hardware being virtualized. Thus the same software executable will run on the Virtual Prototype as well as the physical hardware without modification.

The Synopsys Virtual Prototype was launched in 2006 and is now on the third version. It’s a very new market, so there are continuous updates on the processor core and the available peripheral models. And since the modeling is being driven by standards, the greater silicon community is able to contribute their models, which should make for a comprehensive set of models to simulate just about any prototype you could imagine.

Virtual Prototypes are gaining momentum and being deployed to a wider base of users. Current technologies have only exposed the tip of the iceberg with respect to the end-user benefits. The recently released combined hardware and software analysis and the ability to save and restore the simulation at any point in time let us glimpse the future of this productivity-focused technology.

Summary

I’m really excited about the possibilities and avenues the Virtual Prototype environment opens up for the development, validation, and analysis of new and exciting complex embedded systems now and into the future and highly recommend learning more about virtual prototyping to determine the implications for your product development.

For more information, contact Curt by e-mail at [email protected].