In an EETimes article of 13 June 07, Matt Volckmann, Senior Analyst with VDCs embedded software practice stated that in a survey "44 percent expect to use it [Virtual Platform and simulation tools] within the next two years." He continued: "The challenge of designing and testing software earlier in the design process is becoming an increasingly significant factor, especially in cases where the hardware environment may be extremely complex or not yet available."
More and more people are confirming - it will soon be unthinkable to develop embedded software without using Software Virtual Platforms.
So as of late 2007, what options would you have had if you were needing a Software Virtual Platform of the system you were developing?
There are basically 4 main approaches to obtaining and deploying a Software Virtual Platform methodology: roll your own, contract service provider, license commercial solution, build on open existing source.
This is where you develop models of the different components in your system, encapsulate any 3rd party IP models, and use C, C++ or SystemC to develop them and glue them together. This appears low cost (you dont send many $ out of your company), very resource intensive (but you do spend lots of $$$$ on peoples time internally, but maybe not initially), and you get a bespoke, low quality, low performance, proprietary solution which is often not up to commercial solutions offerings, is not maintainable, does not adhere to any standards, and basically you are on you own. The chances of your models being compatible and interfacing with any external models and technologies is very low... Roll your own means on your own... Good Luck - this is how it was 10 years ago... This is just too hard - and of course building a state of the art simulator is very complex and risky. you need to ask yourself - is this a core competency you should be expending your resources on and need to own?
In this approach you spend many $$$$ getting an outside company to develop the models and platforms for you and build a model of your design. Basically when you have finished your hardware design work you provide full design information to this 3rd party company and they then start to produce a simulation for you. This is like a chip sign-off, and often is only completed at the end of your design process often when the chip is available. Several of these contract service providers were originally set up close to 10 years ago to develop & market their own proprietary modeling solutions but due to the difficulty in using their technology effectively, they have become service providers that use their products internally to develop models for you. Being old technologies they often have challenges being used for modern heterogeneous multi-processor designs and of course by being based on proprietary modeling and interfacing standards - they are not interoperable. And then - they charge you to deploy each copy of the model you have paid for - thus dramatically limiting the usefulness in having the models available - They become just too expensive to deploy. In the hardware world it is routine to have farms running 1000s of simultaneous regression runs. In the software world we expect huge regression runs too and this will be severely limited if the Software Virtual Platforms and individual models need paying for individually... Good Luck - this approach is just too expensive... and the costs are inhibiting rapid adoption.
There are some commercial solutions that are targeted at the user developing their own models. Many of those companies classed as service providers in the section above originally started in this category - but the market found their offerings not usable enough... Often the commercial solutions require learning new proprietary languages making the models not interoperable with other tools etc. The biggest challenge for commercial solutions is that they do not tend to be good enough to really do a good enough job. There are several processor design/modeling languages and they seem to be good at the average core pieces of a processor, however they all tend to fail dramatically when anything out of the normal is desired to be modeled... Of course if you are using a standard core from an IP provider or processor developer, you could buy their models from them and build models of your own components and develop your own platform models using these purchased components.
Open source is an excellent technology proliferation approach that has been widely adopted in the software world, and there are many different places to get open source tools to help with embedded software development. GNU, Linux, Eclipse being well known examples. Related to Software Virtual Platforms are various Virtualization technologies like vmware and QEMU. These technologies are targeted at the system software developer - for example wanting to run Linux on their PC, or Windows on the Mac etc. And yes they may be open source and thus yes you could consider downloading, understanding, and modifying them to do something they were not conceived to achieve - that of providing models that can be put together into an embedded system - however they are very complex pieces of software, that require a large depth of knowledge before there is any hope of any modification, and there is no guarantee that the outcome is what you actually needed...
So - looking at the above it appears that the embedded software community has a significant challenge moving forward when it develops software for SoC and MPSoC. There are no current good solutions existing and the market is fragmented...
It has recently been publicly stated by a senior vice president of a public EDA company that "I see virtual platforms as the ESL killer app we have been waiting for for a long, long time."
If virtual platforms were the killer app, the existing commercial virtual platform solution vendors would be making money hand over fist on their products. Instead, the proprietary nature and capabilities of their modeling tools has forced them all into a services business - which is a challenging business at best.
Already the development cost of the software is more than the hardware in most large chips and many believe that several companies will fail without the right software development infrastructure going forward. Already many MPSoC chip developers failed to effectively develop software for their designs and their companies have ceased to exist.
Since 2004 Imperas has been developing Software Virtual Platform solutions that have been in use at customer sites since early 2006. This Imperas simulation solution has been focused on Multi-Core / Multi-Processor developers is being used as the building block that enables new verification, debug, and analysis tools to be adopted by embedded software developers. Imperas sells verification, debug, and analysis products to developers of Multi-Core / Multi-Processor software.
During 2007 Imperas came to the conclusion that many more SoC/MPSoC embedded software developers would start to fail if the current fragmented Software Virtual Platform situation was not improved.
We came to the conclusion and do firmly believe that a software virtual platform infrastructure should exist to enable model interoperability and it should be freely available. The industry needs a way of converging on a solution where it can improve methodology, productivity, development schedules and really start to manage exploding software complexity.
Without convergence on a common solution there will just be more costs and more pain for SoC/MPSoC software developers.
We believe that Software Virtual Platforms are not the end game of a new software development methodology - they are the starting point - we are not at the beginning of the end - we are at the end of the beginning - like simulation in the hardware world - the adoption of a common way to do Software Virtual Platforms will enable a whole new set of technologies to develop, will enable a whole ecosystem to evolve, will kick-start a whole new era in embedded device software development.
To that end, in late 2007 the management at Imperas made a monumental decision.
"With the creation of OVP we are sharing, making public, and making available our simulation infrastructure technologies with the intention of establishing a common, open standard platform for software virtual platforms for software developers. Imperas will support and initially manage the OVP site, and will contribute much of our innovation to keep this infrastructure evolving. However, it is not solely through our efforts that these technologies will become widely adopted and successful. Participation of organizations and individuals around the world is critical to the success of OVP. We thank all those that are participating in this community."
Simon Davidmann, Imperas President & CEO, Jan 2008.
Fast forward to 2016 and Imperas has again provided more technology to OVP users.
Over years of usage OVP users highlighted some shortcomings and Imperas has been working to address these. There are a couple of main areas. The first is in the ability to model platforms that have hierarchy. Many systems are built by designing sub-systems, or modules and re-using these modules in other designs. For example a microcontroller might have a common central module but many different flavors of part. This has been addressed recently by the creation of the Open Platforms (OP) API in OVP that replaces the ICM API for modeling and controlling platforms. OP has all the capabilities of ICM and much more, including the specification and usage of hierarchical modules.
Another capability now provided with OVP is an Instruction Set Simulator (ISS) that means that you can start developing embedded software for a processor without the need to build a platform. Today in the OVP packages the ISS can make use of over 150 different processor variants without the need to specify a platform. You just load in an elf file, optionally connect up a debugger and get simulating.
With OVP you create platforms and models using C/C++ and make calls to the OVP API functions. Using C and a good API is a very powerful way to build and control models. Sometimes though the use of C and an API can be tedious and error prone. To make writing platforms and models easier, Imperas created iGen. iGen takes a very succinct model description script in TCL as input, and writes out the C files and API calls that define the platform or the models structure. A complex platform can be described in a few 10s of lines of iGen input script that creates hundreds of lines of C calls to the OVP APIs. For platforms and modules most of the description can be written in iGen input script. For peripheral models or CPU models iGen can create the structure and provides the hooks/placeholder C functions for you to add the behaviors you need. The use of iGen dramatically increases your producivity when creating models in OVP. iGen is now part of the OVP packages and follows the same licensing as OVPsim.