Normally when people are introduced to virtual platforms or full-system simulators like Wind River Simics, they jump at the ability to support software development before the hardware arrives. This is certainly an exciting prospect, as we all like shiny new things. What is often not as obvious is the extensive use of virtual platforms to support old, aging, and obsolete hardware.
There is a huge need in industry for easily available instances of older hardware. Virtual platforms like Simics offers one way to improve the situation. Essentially, anything can be made into a virtual platform, whether it is designed tomorrow, yesterday, or twenty years ago. The resulting virtual platform can then run on any current machine, providing the old hardware in stable form without worrying about physical wear or the magic smoke escaping.
It is shiny old hardware, as stable as the day it was first produced. Often, the virtual platform is also faster than the original hardware due to the speed of today's host machines compared to the old machines being modeled.
So, we can model old hardware. Why should we? There turns out to be quite a few applications where this is useful and provides a nice return on investment. Some examples of this that we have seen over the years:
In telecom and other fields, hardware sold a decade ago is often still used in field installations - customers do not upgrade their hardware unless they absolutely have to, and hardware tends to last longer than expected (or planned). Such hardware tends to be built from racks containing lots of boards, and there are usually a large variety of boards with several generations of each board. With a virtual model of the older boards in place, all developers can have their own immediately-accessible hardware to work on. In the physical world, these older boards are often in very limited supply, limiting user productivity.
Another aspect of multi-board rack-based hardware is that modeling old hardware makes sense in the context of building out the contents of a virtual platform for the rack system. With models of older boards in place, the virtual platform makes it possible to test with multiple generations of hardware and software together.
Life-extending older system by software upgrades to old hardware, as is fairly common in the military, aerospace, and transportation fields. The development of a software upgrade requires development hardware, but typically there are very few or no physical units available. A virtual platform would avoid the need to dismantle an actual in-use unit to get development hardware, and provide developers with the rare luxury (in this field) of ample hardware access.
Development boards tend can go bad and become unstable or useless over time. In the aerospace field, I have heard of cases where developers had to buy large supplies of development boards for the processor they were using, at project outset. The development boards were likely to go out of production in a few years time. The half life of the boards was only a few years (they would literally crash and burn). Thus, after a decade or so there would be preciously few development boards left. Using the actual units built for the aircraft is not an option due to hardware cost and those boards not exactly being designed for development tasks. Obviously, a virtual platform is nicer since it will not burn out.
Development hardware can be in limited supply even for established systems. Access to current and older hardware for software developers is limited, as the expense of setting aside boards for development is something a company likes to avoid. This creates bottlenecks in development that can be solved with virtual platforms.
Another interesting use for virtual platforms for old hardware is to simulate faults which have appeared in deployed systems. This moves away from making the hardware shiny, rather making it dirty and dented on purpose. For example, if the target system is flying through space somewhere, a virtual platform on earth can be used to model various faults which have appeared in the physical system during its service life. Software workarounds and patches for hardware issues can then be tested on the ground, in the simulated environment of the virtual platform, before being uploaded to the live system.
The March of TimeAs time marches on, what used to be models of shiny new hardware will eventually become models of old hardware. Making sure to maintain all existing virtual platforms developed for a user base ensures that as time goes on, the library of available systems will just grow. Obviously, if some hardware is really totally discontinued, maintaining the model becomes more an exercise in historical archiving using computer simulation than something useful to the originating company.
Another useful property of virtual platforms is that they do not wear out but can have a virtually (pun intended) unlimited lifespan. If we build a model today for Simics and run it on a Windows PC, it might run on a 64-bit PC with Linux tomorrow, and on some unknown multicore monster with some unknown future operating system in ten years time.
This means that as long as Simics is ported to each new host, the virtual platforms will keep being available. This really offers peace of mind to availability planning for long projects.The virtual hardware will keep the exact same behavior regardless of the host changes, ensuring that regression tests can be run for decades.