As research pushes for better programming models for multiprocessor and multicore (MC) embedded systems, virtual platforms solve one of today's biggest challenges in these systems: software debugging and validation. In addition to enabling software development long before hardware availability, virtual platforms are a practical enabler for MC systems today by their provision of better software development and debugging support than actual hardware. Virtual platforms offer unprecedented control and visibility, along with ease in deterministically reproducing MC problems.

With the right level of model abstraction, these platforms can handle MC complexity while offering high-speed execution of complete MC software stacks and requiring a relatively modest effort for platform development. The key is to use functional transaction-level modeling (TLM) for the virtual platform with abstracted or approximate timing, called Loosely Timed (LT) or Approximately Timed (AT), respectively. This approach relies on high-speed processor instruction-set simulators (ISSs) and high-level, fully functional SystemC/C++ models of the other hardware building blocks.

Even though the use of both homogeneous and heterogeneous MC architectures has increased dramatically, embedded software development practices have not adapted well to the complexities of these architectures. MC architectures pose new challenges in software partitioning and in the mapping of parallel software tasks in an optimized and predictable fashion, as well as in software debugging and validation. Asynchronous interactions among concurrent processors introduce both functional and timing software problems such as race conditions, deadlocks and memory corruption. Worse, their concurrent nature simultaneously makes it hard to pinpoint the causes of system problems.

Even a parallel compiler does not address all the challenges posed when processors overwrite each other's memory areas, lock each other out of shared memory and race to complete tasks sooner (or later) than expected. The debugging capabilities of a physical prototype can typically handle freezing only one processor at a time, leaving the others running, and likely writing over memory locations needed for debugging.

Virtual platforms overcome this challenge by freezing all the processors simultaneously (including all IPC hardware and peripheral clocks) at breakpoints, giving complete visibility into all system states. To help achieve this complete hardware visibility, peripheral functionality can be captured in a graphical finite-state machine (FSM) language that combines graphical flowchart constructs with the execution power of ANSI C. This type of graphical language simplifies descriptions of concurrent hardware interactions and dramatically increases the MC visibility and controllability.

Using this approach, a graphical hardware debugger provides unique hardware visibility and breakpoints to complement the software visibility offered through a multicore software debugger. The graphical debugger also allows unified hardware/software co-debugging. By providing deterministic simulation, a virtual platform ensures predictability. Bugs can easily be reproduced, run after run of the simulation, and faults can be injected at arbitrary times and locations. Moreover, unlike physical trace pods (which have limited bandwidth), virtual platforms can provide unlimited real-time traces.

Getting software months early
The best aspect of virtual platforms is that they can provide excellent support for software development months before the actual hardware is ready. The complexity of MC SoCs leads to such long hardware design cycles that the traditional hardware-then-software development flow pushes system development cycles to absurd lengths. Using a virtual platform helps cut a significant portion from this cycle by overlapping hardware and software development.

In light of the multitude of challenges in managing interprocessor communications in MC systems, the head start provided by a virtual platform dwarfs the time required by any rework caused by changing hardware details. Experience has shown that it is even worthwhile to begin software development while the architectural specifications are still being determined.

The virtual platform offers many benefits on the hardware side by enabling hardware verification at the system level rather than just at the block level. Also notable is the ability of virtual platforms to help in the development of power-conservation strategies. The greatest power savings come from making the right architectural choices (such as serial-vs-parallel processing). For example, when developing an MC SoC, are six processors really needed, or can five do the job if they execute more tasks serially? A virtual platform helps answer such questions.

How to build a fast virtual platform
To support high-level MC OS porting, middleware integration and application development, MC execution speeds are needed at multiple tens of MIPS. A virtual platform cannot rely on cycle-accurate simulation, which typically tops out at around 500 kiloinstructions per second (kips) and clearly does not scale for MC architectures.

As mentioned earlier, the speed needed is available from loosely timed (LT) or approximately timed (AT) functional transaction-level modeling (TLM). Even for systems involving many heterogeneous processors, dozens of peripherals and multiple bus interfaces, an LT platform executes Linux and applications at many tens of MIPS.

LT virtual platforms achieve such speed by focusing on the hardware details that affect, and are exposed to, software running on these systems, along with reduced timing detail. For processors, this means that the virtual platform executes target program binaries on an instruction-by-instruction basis and is thus binary compatible. Functional models of the memory management unit (MMU) and caches provide runtime statistics on cache hits and misses. In the interests of speed, however, the platform avoids processor details that are not exposed to the programming model, such as the processor's pipeline.

Similarly, LT platforms use bus models that reduce complex bus traffic to simple read and write transactions with representations of address decoding and control registers for elements such as bus bridges and arbiters (but no detailed bus phasing, arbitration or timing beyond simple access delays). Because MC systems tend to have many crucial peripheral interactions, virtual platforms must also include peripheral register interfaces, programming models and functionality while communicating with other peripherals or the system I/O.

AT-level platforms increase the timing detail by including approximate cycle models of the CPUs; cycle-approximate bus models that add arbitration, pipelining and concurrency aspects; timing approximate memory controller models (because often these MC architectures are shared (off-chip) memory architectures) and access timing for off- and on-chip peripherals. At this greater level of timing detail, these platforms provide solutions for more detailed MC software partitioning, performance tradeoffs and debugging of time-dependent functional MC problems, such as race conditions.

The TLM virtual platform market is maturing. Standards for TLM interfaces and abstraction levels are developing, and model availability is increasing. The most well-developed standard is the TLM 2.0 standard recently proposed by the Open SystemC Initiative (OSCI). Focused on high performance, this standard will enable the plugging together of TLM models originating from different IP sources and model suppliers at different abstraction levels. Transaction-level processor models are available today from different sources, including processor providers and EDA vendors (Synopsys's DesignWare System Level Library, for example). Virtual platform development environments, such as the Synopsys Innovator, provide productivity solutions to tackle MC modeling.

With this approach, concurrent hardware/software development can cut enormous amounts of time from the development cycle. MC architectures offer a great deal of flexibility, and virtual platforms help to fully realize that potential by providing a way to refine the killer apps that make products shine.

Filip Thoen (Filip.Thoen@synopsys.com) is solutions architect in the system-level solutions group at Synopsys. Prior to joining Synopsys, he was CTO and cofounder of Virtio Corp., a market leader in virtual platforms that was acquired by Synopsys in May 2006. He received his PhD in Electrical Engineering from the Catholic University of Leuven, Belgium, and has worked as a researcher in the IMEC research institute.