Rethink your project planning with a virtual platform

A virtual platform is an embedded computer system simulated on a regular PC. The virtual platform behaves like the physical target hardware and can boot and run the complete software stack, providing a platform for architecture definition, system and software design, test, debug, and training.


Virtual platform technology has been used to simulate a very diverse set of targets, from single-processor boards to complex multi-core, multi-board, and rack-based clusters.


They are very useful for system and software development and design as well. Virtual platforms are used across the product life cycle, from initial product definition, through development, and on to deployment and long-term maintenance.


From more than a decade of experience providing virtual platforms to system developers and original equipment manufacturers (OEMs), we’ve found that virtual platforms can have a truly revolutionary effect on software development.


But while the benefits for software development realized by using virtual hardware are certainly nice, embedded developers will not be able to take full advantage of virtual platforms if they only look at them as just a tool to improve software development in isolation does not realize its full potential impact.


A good case in point is project management.


Project Management and Planning Impact

After an initial project, users of virtual platforms will realize that many software development tasks can be reduced in time or be moved up within the project schedule. By taking these improvements into consideration when planning a new project, a very different project plan emerges.


New Hardware. For projects involving developing software for new hardware, the early and wide availability of virtual hardware compared to physical hardware enables a number of schedule improvements:


* It is possible to decouple the hardware and software development and delivery schedules. The scheduling of the software is only dependent on the finalization of a hardware design, not on its actual physical availability.


* The start of software development can be scheduled with greater certainty because the limiting factor of hardware availability is removed. This greatly reduces the ripple effect of hardware delays on the overall project.


* Software development can ramp up faster, again because it is not tied to hardware availability.


* Overall project risk is reduced because unexpected delays in hardware availability (e.g., a key chip or processor not becoming available from the vendor according to initial plans) do not impact software development.


* Once the hardware appears, bringing up the software on the physical hardware is a much shorter and smoother process. Most bugs will already have been found and fixed and what remains are often bugs related to detailed hardware timing and analog effects of printed circuit board (PCB) design. The difference in development time can be striking, reducing the time to a working system by several months.


* Hardware and software developers can cooperate around the virtual model and provide mutual feedback on the design earlier than otherwise possible. This tends to avoid hardware design mistakes that make life unnecessarily hard for the software developers.


Existing Hardware. When software is developed for existing hardware, virtual platforms still allow for efficiencies in development that reduce project lead times:


* The easy and scalable availability of virtual hardware makes it possible for an individual developer to test new code and changes in a complete, integrated system environment. This tends to catch obvious errors immediately, saving the latency and effort of sending the software to a specialized system integration and verification group. This also leaves the integration and verification teams free to concentrate on more difficult errors and integration work.


* Since virtual platforms run the same software as the physical platform, there is no need to maintain a separate software build for desktop emulation as is commonly done today. With virtual platforms, the development build and the release build are the same, saving the cost of maintaining another build target.


* The debugging facilities of virtual platforms reduce the time required to find and correct software bugs. The precise effect of this on a particular organization will have to be measured over time, but it will translate to a reduction in typical software development time. We have seen cases where average bug resolution times go down by a factor of four or more.


* The debugging facilities have a huge impact on the hard bugs, the ones that keep development stalled for weeks and software engineers tearing their hair out. Those bugs tend to be intermittent and hard to reproduce on physical hardware systems. We have seen bugs that take weeks or months to correctly diagnose on physical hardware be found in a matter of hours or days using virtual platforms. This reduces the risk of major stalls to a schedule due to a really nasty bug.


* Virtual platforms create better bug reports because more system state can be observed and it is easier to capture and diagnose software activity. The net result is that bug reports take less time to assign to the correct team and thus lower turnaround times from error discovery to correction of the underlying fault.


* With virtual platforms, it is possible to trace the interaction between software and hardware in a system. This makes it easy to resolve a conflict between software and hardware teams over where the root cause of a non-functioning system is to be found, reducing the typical rounds of discussion over where a problem is located.


* Virtual platforms make it easy to automate regression testing because there is complete control over the target system. Reboots, resets, and result checks are very reliable. System snapshots can be used to avoid repeating lengthy processes such as system boots and software loads.


* Virtual platforms make it easy to share a buggy system state and the history leading up to a bug between developers and between testers, users, and developers. By replicating a bug in many places at the same time, high-priority bugs can be worked on in parallel by several developers or teams.


* Virtual platforms allow testing to be done in parallel, running many virtual platform instances on clusters of host machines. This can cut the execution time of massive test batteries down to a level where they can be run daily rather than weekly, making it harder for bugs to sneak back in and providing a higher-quality end product.


Virtual platforms are a key technology for the future of embedded software development. Virtual platforms makes it possible to decouple software and hardware development and to achieve significant improvements in the software development process that in the end translates to better products that get to market sooner and in a more predictable way.


Jakob Engblom is Technical Marketing Manager for Wind River Simics, a full system simulator used by software developers to simulate any target hardware from a single processor to large, complex, and connected electronic systems. He has been working on Simics since 2002, and today works on product planning and how to apply Simics to customer problems. He holds a PhD in real-time systems from Uppsala University and an MSc in computer science, also from Uppsala University. He has written and presented more than 100 articles and talks on a variety of embedded systems topic since 1997.

Leave a Reply

Your email address will not be published. Required fields are marked *

*