Virtual Prototyping for Early Software Development

By Filip Thoen

Rapid progress in silicon technology is enabling the integration of complete systems on a single chip, and making every System-on-Chip (SoC) design a complex real-time embedded system. Traditional software development techniques have failed to keep pace with this integration, resulting in delays getting new products to market. The emerging technology of ‘virtual prototyping’ reduces the risk of schedule slips by enabling early software development and continuous integration of hardware and software as chips are being designed.

Even though every delay in product launch causes significant loss in market share, most embedded systems designs are late to market. A 2003 survey by Embedded Market Forecasters (Framingham, MA) put the number of embedded projects not completed on time at more than 50 percent. The reasons cited for this widespread slippage in schedules are the increasing complexity of embedded systems, higher levels of system integration driven by ever shrinking hardware geometries, and a late start in the complex and laborious task of hardware/software integration.

The challenges can only grow. The increasing complexity of systems implies more software to implement, forcing the use of third-party software such as operating systems, middleware, and application code. In addition the average software content of today’s embedded systems is increasing to supply increasing functionality, meaning even more software to be validated and integrated.

To make things worse, highly integrated devices often feature complex on-chip peripherals and hardware accelerators that the software relies on to provide the system’s required functionality, performance, and power. Developers need to verify that that the combination of software and hardware matches the expected functionality and performance. Performing this verification requires control and observation of the hardware with awareness of the software execution.

The complexity of this task is aggravated by the limited system visibility, poor ability to trace system software in real-time, difficulty in controlling system execution, and intrusion during measurement that traditional tools produce. In addition, a high degree of integration typically renders some of types of on-chip resources, such as internal dedicated buses, inaccessible even for advanced debugging probes such as JTAG. Run-time tracing of these systems is also rendered difficult by limited visibility into the system and by the bandwidth limitations of the debugging probes employed.

Given the difficulty of hardware/software integration, it makes sense to begin the effort as soon in the development cycle as possible. Unfortunately, a major impediment to starting software development, and more specifically hardware/software integration, is the unavailability of target hardware until late in the cycle. Not being able to close on the complete system functionality until the end of the design cycle, when a physical prototype finally becomes available, introduces a huge risk of product delays.

Traditional Software Development Approaches

Several solutions have traditionally been available to embedded software developers, featuring different trade-offs in execution speed, level of accuracy, invasiveness, flexibility and cost. But today’s high-speed, deeply embedded processors have reduced the usefulness of traditional development tools. Each type of traditional tool has limitations when dealing with SoC designs.

In-Circuit & on-chip emulators -Classical in-circuit emulation (ICE) systems provide fine-grain execution control, precise tracing through powerful triggers, and performance feedback through detailed event collection. However, today’s SoC technology has made the traditional ICE impractical. An ICE requires connection to the processor’s system buses, and SoC processor buses are buried inside the chip unless the processor designers and silicon vendors to provide a means of access.

Co-operation between the silicon providers and software development tool vendors has created on-chip emulation facilities, typically relying on on-chip JTAG interfaces. While on-chip emulation allows the real-time control of a microprocessor, however, the observation and data acquisition uses a bandwidth limited JTAG connection. The bandwidth limitation inhibits the ability to perform a real-time software trace. In addition, the complexity of today’s system buses requires more access points than are practical to implement. As a result, some resources remain hidden.

OS simulators- Several OS simulators, sometimes called ‘software emulators’, are available for leading embedded real-time operating systems (RTOSs). Being a port of the target OS to the host development system, these simulators run the RTOS in a ‘sandbox’ environment and support the debugging and execution of application code for the target OS right on the host development system. However, while appropriate for specific types of application development-these simulators boast speeds well over 50 MIPS because of their native character-they fail for lower-level software development tasks. They do not provide sufficient detail about and access to target hardware. They simply emulate the API of the target OS and do not model ASICs and hardware accelerators.

Developing on the host system rather than the actual target also introduces some artifacts. The speed and memory footprint of the application on the host system is not an accurate indication of the target system’s performance. In addition, the user interface might be dramatically different on both systems. Finally, depending on the resemblance between host and target system, developers often find themselves performing considerable effort in porting the application over to the target when development is completed.

Hardware/software co-verification-Today’s hardware/software co-design and co-verification approaches proposed for SoC designs are geared towards the refinement of a design into its silicon implementation. These approaches typically consist of a cycle-accurate processor instruction-set simulator connected to a Hardware Description Language (HDL) simulator. Hardware designers can use the approach for verification of the hardware/software communication mechanisms. While valuable for hardware development and evaluating small amounts of software interacting with the hardware, however, the detailed HDL hardware models limit the simulator’s performance and its utility for software development.

Co-verification systems can typically execute on the order of 50,000 instructions per second. This is not practical for running the system software; it is orders of magnitude too slow to run a sizeable application. Further, co-verification systems only become available late in the design cycle, so they do not effectively enable early software development. Also, the HDL language paradigm does not fit well with software developers, who typically are familiar with C/C++ but not with hardware description languages. Finally, these systems are expensive, making it neither practical nor cost effective to put them on every software developer’s desk.

Other techniques-To solve the speed issue of co-verification, people have relied on FPGA prototyping systems. These are massive logic hardware emulation systems, early reference boards, or specifically developed board prototypes to develop and run the system software. The first two types require considerable progress on the hardware development front before they can be created. In addition, creating logic emulation involves a complex and elaborate mapping process and the emulation systems is seldom justifiable because of its high cost. Early reference boards are typically too different from the final system to be usable for detailed software development. In addition, they along with prototyping boards can only be built when first silicon becomes available. Again, this places them late in the development effort.

Virtual Prototyping-An Emerging Technology

The software design process includes many stages, including specifications, coding and integration. Each stage introduces bugs, but traditional techniques typically don’t allow software test until near the end of the process. Further, they cannot bring all the system pieces together early in the design cycle where there is the greatest flexibility for change. As a result, bugs accumulate until the end of the design, where they are the hardest to find and fix.

A more ideal design process would support iterative design, allowing developers to test software and find the bugs at each stage before moving on. This would minimize the accumulation of errors and allow changes to be made while the design is most flexible. To accomplish this, however, software developers would need a target system to develop and test on, ahead of hardware availability.

A breakthrough technology, virtual prototyping, provides such a target system. Virtual prototyping technology creates a high-level software-based embedded platform that can fully mirror the functionality of a target SoC or board. These virtual platforms combine high-speed processor instruction-set simulators (ISSs) and high-level, fully functional, C/C++ models of the hardware building blocks through software modeling of the target hardware. These virtual platforms serve as a target for developing software before hardware is available. Further, they provide greater accessibility to the target’s internal resources than can hardware platforms, even when they are available.

Simulation is not new, but its adoption by software developers has been prevented in the past by many drawbacks. One is low simulation speed, mostly attributed to the high degree of accuracy that HDL models provide, requiring significant processor resources to generate. Another drawback is the expense, both in the time needed to create the simulation model and in the cost of the simulation tools. Further, the HDL models do not integrate well with existing software development tools, making them hard for software developers to use.

The key to improving simulation speed is adapting the level of detail to suit the needs of software developers, i.e., controlling the abstraction-level of the models employed. Virtual prototypes can span multiple levels of accuracy, ranging from functional-accurate to timing-accurate to cycle-accurate models. They may combine instruction-accurate or cycle-accurate processor models with functional, timed and cycle-accurate peripheral models, and employ appropriate bus functional models where needed, to match each element of the simulation to the developer’s need for detail at any given stage of the development.

In Virtio’s experience, transaction-level, register-accurate functional models suffice for early software development and integration and are abstract enough to achieve the execution speeds required for these phases. For this early development stage, virtual prototyping may combine instruction-accurate processor models with less-accurate busses, where the bus behavior is modeled as abstract read or write memory transactions. At this stage the peripheral models also have relatively little detail; the register interface combined with the functional behavior suffices. Timing aspects that contribute to the correct system functioning, such as time ticks delivered to the OS by a real-time clock peripheral, are also modeled. Even at this level of detail in the model, however, binary compatibility with respect to both program executables and register interfaces is achieved.

These models do not operate at real-time speeds, prompting many developers to deem them insufficient for debugging, Yet, inserting cycle- and/or clock-accurate information in these models would render them too slow to be effective in software development. In addition, the development time for the more accurate models would delay their availability until late in the development and would require considerable resource investments.

Fortunately, the criticism can be addressed another way. The high-level models can provide detailed profiling information, such as cache behavior, trapping and exception statistics and instruction profiling, that can be extrapolated to first order clock cycle performance estimates. Thus, developers can analyze the software performance to anticipate its real-time behavior and identify potential problems even without running at real-time speeds.

Figure 1: Virtual prototyping replaces missing target hardware with a functional simulation, but allows connection of external hardware to provide full system operation during debug.

Components

A virtual prototype, as shown in Figure 1, builds upon a number of components. These include:

• Fast processor models: or instruction-set simulators, connected to commercial software debuggers, enabling the loading and execution of the real software on the virtual prototype.
• Hardware / peripheral models: standard processor peripherals, busses and logic accelerators captured as high-level C/C++ models, then compiled and executed on top of a system simulator to quickly model the hardware portion of a design.
• Co-simulation APIs and backplane: connecting the processor models and the system simulator, these enable a seamless communication between the hardware and software domains that takes care of the prototype’s global coordination.
• Test-Bench / human-machine interface models: like the keyboard and LCD of a cellular phone or PDA, mimic the real appearance of and interaction with the system being designed.

Some of the desirable characteristics of virtual prototyping and the virtual platforms developed in it include:

• Modeling ease & productivity - although virtual prototyping supports the re-use of hardware IP models, application-specific components need to be able to be captured easily, in matters of weeks rather than months to avoid spending more time on the prototype creation than on the actual software development.
• High execution speed - the choice of the appropriate abstraction level combined with optimized simulation technology will render models fast enough to make the virtual platform effective as a development target in an iterative ‘edit-compile-debug’ cycle. Equipped with enough speed, commercial operating-systems including Windows® CE, Linux®, Symbian OS™ and Palm OS® can be booted in 10 - 15 seconds,
• Binary compatibility - when employed with the right modeling accuracy, virtual prototyping should support the development of production-quality software, requiring no change when the physical system becomes available. This is essential to effectively tackling the hardware/software integration problem. Without binary compatibility, a porting step would be needed to move the software to the hardware target, introducing a new opportunity for bugs to develop.
• Virtualized physical connections - virtual platforms should offer physical connections to the host computer’s network, keyboard, mouse, USB, PCMCIA card, and so on to provide software developers access to all the functionality they need to test applications, middleware or device drivers. For example, such connections would remote software debugging tools to connect to the platform over a virtual Ethernet connection or allow the virtual platform to browse the Web when running a web browser application on the target.
• Advanced user interfaces & skins - virtual platforms should model the touch screen and configuration switches, and support different product skins. This is required for application developers to render screen output on the actual screen form factor, and for QA engineers to test the end product with its actual user interface.
• Visibility & Controllability - through employing a graphical modeling language that extends the C programming language, virtual prototypes can provide complete visibility into and controllability of the hardware it is modeling. A hardware debugger that provides hardware tracing, single-stepping, and break-pointing can then support software development.
• Extendibility - virtual platforms are different from OS simulators in that they are not fixed, and should be able to be extended by the end-user to incorporate new library and user-created hardware component models.
• Seamless integration with industrial software development environments (IDE) - this is essential not to disrupt developers’ current workflow. Integration happens through standard debug interfaces such as RDI, MDI and GDI for low-level control or through virtual physical connections for remote debugging tools employed for application development.

Figure 2: Virtual platforms, such as the VPXS Virtual Platform (top) for Intel� Xscale� technology-based processors, can run standard operating systems such as Microsoft Windows CE (front) and work with popular software development tools like Microsoft Platform Builder (far left).

Additional Benefits

Virtual prototyping enables a true early start of software design and promotes the concurrent engineering practices for software and hardware development. The software nature makes it affordable enough to give every development team member a virtual prototype to develop and debug on, promoting faster design efforts. In addition, virtual prototyping replaces time-consuming hardware/software integration late in the development cycle with continuous integration throughout the whole software development.

The technique also offers benefits even when hardware is available for software development and debug. Because the virtual target is software based, it offers much greater flexibility than the hardware target when it comes to coping with change or design derivatives. Debugging with the virtual prototype allows hardware changes to be accumulated and tested before making another board revision or silicon spin. The software target also provides virtually unlimited observability and controllability; it is not limited to the available pins or JTAG bandwidth as on a hardware prototype. In addition, the virtual prototype can be halted and inspected as desired, and profiling information can be generated on the fly. These features are especially useful when designing complex software components touching the hardware/software boundary, like device drivers.

Virtual platforms are available for a number of processor devices. For instance, CVirtio and Intel have created the VPXS, VPXS-WM and VPXM Virtual Platforms, which are high-performance software models of the Intel® XScale™ microarchitecture family members. The VPXS platform, shown in Figure 2, and VPXM model the Intel® PXA250 and PXA 270 Applications Processor development boards respectively. The VPXS-WM adds Intel® Wireless MMX instruction extensions to the PXA250 processor. For each of these Virtual Platform products, a Platform Development Kit (PDK) is available as an upgrade, which adds Virtual Platform model authoring tools to the product. The Intel® development boards focus on hardware prototyping of ASICs and SoCs by providing extendibility through the on-board FPGA chips, and allow hardware designers to develop an early hardware prototype. In a similar fashion, the Virtio Virtual Platforms focus on early software prototyping, development and integration by providing control and visibility into the hardware for software developers. The PDKs allow extension and customization by adding user-specific components and peripherals. Also, the PDK provides a customizable user interface and graphic skins for early product evaluation.

Virtual prototyping thus provides an attractive alternative to traditional debugging techniques for developing embedded software. The technique is compatible with standard software development tools, fast enough to support an iterative ‘edit-compile-debug’ development cycle, and effectively behaving as a target board.

Virtual prototyping will not offset classical emulation or prototyping techniques; these still have their place in the development cycle. Rather, it can complement them and promote an early start to software development for new hardware designs. Starting software development early allows more time for debugging and integration, and can keep embedded system development on schedule.

---

Filip Thoen is the Chief Technical Officer and has over 10 years experience in high-level synthesis, retargetable code generation, HW/SW co-design and system-on-chip (SoC) design. Prior to joining Virtio, Filip worked as research staff engineer and chief system architect at National Semiconductor. Filip received his Ph.D. in electrical engineering from the Catholic University of Leuven (Belgium) and worked as a researcher in the IMEC research institute.