The development of the hardware (HW) platform — system-on-chip (SoC) or board — and the application software (SW) is usually done by separate teams, and often by separate companies. In general, the hardware platform development team includes software engineers in charge of developing low-level platform-dependent software — also called firmware (FW) — including boot loaders, C runtime and libraries, operating systems and device drivers. Software engineers also usually develop middleware (MW), including protocol stacks and various libraries, providing specific application programming interfaces (API) to application software developers — the platform users.

One of the biggest challenges for such projects lies in the interdependency between application software and hardware platform development. In order to design an efficient platform that accurately serves the needs of one or several applications, platform developers must have a good understanding of the target applications. And, in order to develop their software, application developers need to understand and make the best use out of the hardware platform. Waiting for the completion of hardware before starting the software design has two major drawbacks:

1) The final system validation happens at the end of the project, after many man-years of efforts have been invested. This leaves the engineers with limited flexibility for optimization and addressing potential product defects.

2) The time-to-market objectives cannot be met since the software development effort requires the majority of the project schedule, and hence a large monetary investment.

Therefore, the following needs have risen on both platform and application sides:

1. Platform developers need to specify, architect, develop and validate their programmable board or chip for specific uses before the embedded application software code is available.

2. Application developers need to specify, architect, develop and validate their software before the real platform hardware is available.


Hardware virtualization for early software development
The hardware industry has been addressing the second need for many years in different ways. As opposed to software production, hardware production requires heavy manufacturing efforts. Software production requires a compilation step: from software programming language such as C or C++ to machine code. Programming the execution platform is simple and consists of loading machine code into a persistent data storage device such as flash or programmable memory. Hardware production goes through two synthesis steps, each of equivalent importance: front-end from hardware description language such as VHDL or Verilog at register transfer level (RTL) to gates, and back-end from gates to silicon. Still, an actual physical device has to be manufactured.

Since producing hardware requires more steps and is much less flexible than software production (a hardware re-spin of a large chip can cost more than a million dollars), the hardware industry has developed ways to accelerate the availability of a programmable hardware platform so hardware/software (HW/SW) joint execution can be verified and validated as early as possible. This way, software developers don't need to wait for production chips to start programming and hardware developers avoid costly manufacturing cycles. Hardware developers use techniques to provide a virtual software execution environment that can run the embedded software in a similar manner than the real hardware platform. Virtual software execution environments may not be as fast or as accurate as the real hardware, but they can be obtained earlier at lower cost. They are also more flexible and less expensive to adapt or fix.

The first step towards virtualization is to provide pre-silicon prototypes, like reference implementations for off-the-shelf silicon, field-programmable gate array (FPGA) prototypes, emulators or RTL simulators. Today, the EDA industry, particularly electronic-system level (ESL) vendors, is working on the second step: providing pre-RTL/pre-gate prototypes, called virtual platforms. In this paper, a virtual platform refers to a transaction-level (TL) or cycle-accurate (CA) model of the hardware platform, and virtual prototype refers to a RTL model of the hardware platform. All of the virtual software execution environments have the ability to execute the real software machine code (instructions) obtained by cross-compiling the application software program for the targeted processor. An example of a virtual target processor that can run the real software machine code is an instruction set simulator (ISS). Such virtualization techniques imply that full-system verification and validation relies on HW/SW co-simulation or co-execution, which can be achieved only when all models of hardware components and the full embedded firmware, middleware and application software are available.

Virtual platform development environments provide an efficient solution for creating virtual hardware platforms for early embedded software development with fast ISS. Virtual prototypes are HW/SW co-verification environments. Most virtual platform environments are built with SystemC today. Creation of a TL or CA virtual platform relies on the assembly of models of standard hardware components or intellectual property (IP) blocks available in library. Proprietary or third-party IP that cannot be found in a vendor's library must be modeled by the user or a subcontractor, which requires time and money.

HW/SW virtualization for continuous system specification and validation
In order to deliver a virtual platform environment that enables early software development, platform providers must provide full hardware virtualization. They need to solve the first problem of the availability of HW IP models required to build a complete virtual hardware platform model. However, how can the vendor guarantee that the platform suits the needs of the application? Architecting, optimizing and validating the hardware platform without the application software require creating representative test cases to monitor the virtual hardware platform model in situations that mimic the execution of the future software application. Ideally, platform developers should get those test cases from application developers. From the same use cases and application model, application developers could derive specifications for application development and test cases for platform validation.

Even though virtual platform challenges —availability of IP models and creation of realistic test cases— could be addressed, a virtual software execution environment does not solve the problem of architecting and optimizing the system. In fact, the whole problem of system architecture has to be looked before the first line of software or hardware code is written. In order to be fully optimized, hardware and software should be jointly specified and architected before development starts, when choices can have major impacts. Only exercising realistic use cases on executable specifications of the full system can deliver useful data for optimizing the system.

In order to solve these problems, a new, fourth virtualization step is required. This step not only involves further hardware virtualization, but also requires software virtualization. The objectives are to free developers from the constraints of executing software instructions on ISS and building virtual hardware platforms from IP models. The model obtained can be qualified as a virtual system, since it encompasses the full HW/SW system. The table below illustrates the differences between virtualization techniques.

Click on image to enlarge.

The use of a virtual system can be shared between application and platform developers at three stages:

. Stage One
Application developers create behavioral models of their application with use cases to drive simulations. The simulations enable the developers to verify and validate their models. Such models run on abstract platform models and constitute executable specifications of the system. Platform models are built from generic hardware components such as processors, busses, memories and peripherals. Instead of relying on a library of models for each and every hardware part on the marketplace, generic models capture the universal nature of classes of components and provide customization parameters to tune the characteristics. This way, a first outline of the hardware platform can be built very quickly, or several platform architecture options can be evaluated if the real platform does not exist yet. Software is not executed on such platforms, since only a behavioral model of the application is created. The full-system validation can be achieved by fast host-based simulation. As there are no ISS and no instructions to run, the application model provides budgeted execution times that the simulator uses for analyzing the performance of the system. Other requirements of the application or platform, such as power consumption, memory footprint, area, cost, can be characterized and analyzed at simulation time. This enables estimating a global architectural overlook of the system. . Stage Two
Application models executed on the abstract platform model during stage one are translated into SystemC or another format and used to feed virtual platform simulations through traffic generator interfaces. As application models created at the first stage are executable specifications of the real application software, they perfectly mimic the workload of the application running on the hardware platform. These models can be used to validate the virtual platform model. They serve as test case models to stimulate virtual platform models when application software is not available yet.

.Stage Three
The virtual platform is ready to host and execute the embedded application software based on the initial executable specifications provided at stage one. The initial first-stage use cases can be reused as test cases to drive the HW/SW co-simulation. Performance figures obtained during simulation at this stage are more precise than the initial budgets or requirements of stage one. The first-stage virtual system model can be back-annotated with these increasingly accurate measurements to provide future projects with well-calibrated models.

The following figure represents the different stages explained above:

Click on image to enlarge.

However, for true system-level specification and architecture optimization, full-system virtualization is required, including abstract models of HW, behavioral models of application SW and use cases. Such a virtual system can be obtained earlier since it does not rely on the availability of HW IP models and SW code. Use cases developed at this initial stage can be reused at later stages to validate virtual platforms and prototypes. Delivered executable specifications with virtual system models also provide for the development of new HW platforms and application SW.

CoFluent Studio (www.cofluentdesign.com) is an example or such an embedded system virtualization environment.

About the author

Vincent Perrier CoFluent Design's executive officer