Let’s start with some thundering generalisations. It is taking too long to bring SoCs to the market. A big bottleneck, and a large and growing part of the overall cost of an SoC, is developing the software to run on the embedded processors. It is often not possible to begin software development until the chip architecture has been pinned down, which severely limits the influence that the software team can have over the architecture. The desk-top development environment, in which software is usually developed, behaves differently to the target environment. Hardware prototypes in, for example, FPGAs, if they are created, are different again, expensive to create and usually available only late in the development cycle. When the chip becomes available, debugging software running in it can be a nightmare.
This string of problems is only going to get worse as multiple cores, heterogeneous and homogeneous, become the norm for SoCs. If it is not easy to develop software for a single processor, software for multiple processors is recognised as being even more difficult to write and horrendously more difficult to debug.
OK. Common ground so far, and almost every presentation you have sat through covers aspects of this. Why rehearse it again?
Because, if Simon Davidmann and his team at Imperas have got it right, the situation is changing and changing radically.
Simon Davidmann is a very successful serial entrepreneur, with enormous experience in EDA. His web-based CV (Curriculum Vitae or Resume) lists 5 start-ups where he played a significant role. Much of his work has been with some aspect of EDA pioneering, and the list includes names and products like HiLo, SystemVerilog, VCS, and Ambit. His last company, Co-Design Automation, which he co-founded in 1998 and managed as President, CEO and Chairman, was sold to Synopsys for $36 million in mid-2002. He left Synopsys in 2003 and soon after founded Imperas. He (and his team) then spent several years (and, he estimates, about $4 million) developing the basis for a solution of the SoC software problem – a virtual modelling environment for developing software for systems using multiple processors.
Then what did he do?
He only went and gave all that work away, for anyone to use, by putting it in the public domain, as the Open Virtual Platform.
Davidmann did this for a mix of reasons, but the key one was to get much faster adoption of the platform. This will allow Imperas to make money out of the tools that will be needed to develop and debug systems that have been created using the platform. (For a more detailed discussion on new aspects of open source and the growth of cooperation, have a look at Embedded Technology Journal.)
The OVP is aimed squarely at the software developer, unlike hardware emulation/prototyping. It provides an instruction-accurate model of the entire system, and it can include modelling the environment that the system will interact with. It is not designed for hardware debug: for example, bus models don’t include timing. Instead, they have just enough functionality to run the final software without any modifications.
What OVP does give is hundreds (or even thousands) of MIPS throughput, running unmodified production binaries on a desk top PC under Windows XP. To repeat, it executes, at real speeds or better, the real code that will be running in the final product.
This is achieved by building models. There are several levels of open source models available on the OVP site, in three categories: platform models, processor models, and peripheral models. On the web site, the platform models range from “bare metal” (that is a single processor with memory) to a model of a full MIPS Malta development board complete with Linux. (And, it is claimed, Linux will boot on the model in under 4 seconds.)
Processor models include verified MIPS cores and other cores from ARC, ARM and OpenCores’s OR1K. Wrappers are available that allow Tensilica Diamond models to appear to an OVP platform as a normal OVP processor model. The wrapper approach can also be used with existing ISS models, although the execution may not be as fast as a model created for OVP.
Peripheral models include generic models of RAM, ROM etc, PCI, UART, VGA, all created by Imperas and donated to OVP, and a USB host, donated by SiBridge.
The OVPsim simulator provides the infrastructure for integrating the hardware models to create the platforms and system models. It will simulate multiple processor systems, either homogeneous or heterogeneous, whether linked by buses or different kinds of shared memory. Imperas has used OVPsim to simulate platforms of up to 1000 processors. The open source OVPsim runs on Windows XP, but even more powerful versions, running on different operating systems, are available from Imperas. The speed of execution comes in part from OVPsim dynamically taking the instructions of the processor model and mapping them onto the instruction set of the underlying processor.
The OVPsim platform models can be hooked up to an external debugger that uses the GNU GDB RSP protocol. The compiled models are shared objects, so they can be encapsulated in any simulation environment that is able to load them, such as C, C++, and SystemC simulation environments. The advised route is through the new OSCI TLM 2.0 interface.
To build the models, OVP provides a number of APIs. The main ones are:
ICM, Innovative CPU Manager, for creating platforms.
VMI, Virtual Machine Interface, for creating processors.
BHM, Behavioral Hardware Modelling, for behavioral modelling.
PPM, Peripheral Programming Model, for peripherals.
While all the APIs are important, perhaps the VMI can be seen as the central API, since it allows people to build processor models: the OVP site claims, “Typically a 32 bit RISC can be written in 6-8 weeks and will run at up to 500 MIPS on a 3GHz desktop PC.” Within the processor model, it is possible to create a range of features, including MMUs, TLBs, and different processor operating modes. Multiple processors can be created for a single platform. VMI can provide semi-hosting capabilities within OVPsim to allow non-intrusive application instrumentation (instrumentation that has no affect on the application behaviour).
Processor models themselves are not enough to represent the behaviour of a system; they need peripherals, and they need some representation of system behaviour, and for this OVP provides PPM & BHM. Models using these APIs run in a protected environment (and so cannot crash the simulator) and run on Peripheral Simulation Engines (PSEs). BHM is for modelling processes, delays and event, while PPM models the interface to the platform bus ports and net ports.
ICM (Innovative CPU Manager) pulls all these elements together. It allows instantiation of multiple processors, buses, memories, and peripherals, described using the other PAIs, and it allows buses, memories, and processors to be interconnected in arbitrary topologies. For example, arbitrary multiprocessor shared memory configurations and heterogeneous multiprocessor platforms can be modelled. ICM calls are used to load application programs into simulated memories and then to simulate the platform.
With these tools, developers using OVP should quickly create a virtual platform. This can be used by multiple teams to create software that will run at real speeds (or even faster) under the real operating system, well before the target hardware is ready, and even before a hardware virtual platform or emulator can be built. If the process is started early enough, the results of the simulation can be used to optimise the relationship between the software and the hardware architecture, rather than, as frequently happens today, the software having to make compromises to fit the locked- down hardware.
EDA and formal verification guru, Brian Bailey, in a long white paper on OVP has said that OVP, “… may provide the missing part of the puzzle to jump start successful commercial deployment of ESL (Electronic System Level) flows.”
For OVP to take off requires that the OVP community continues to grow and to add to the libraries. In particular, to match the requirements of many SoCs, it will need to add verified ARM models and DSP models. The list of companies already involved with OVP is growing, and Davidmann hints that there announcements to come that will help to ensure the wider acceptability of OVP.
More information: www.OVPworld.org & www.imperas.com
