When you explain what a virtual platform or full-system simulation solution like Wind River Simics is, a key part is that it runs the same software as a physical board or physical system. This does capture the core of the idea – but it does not mean that the virtual platform is only "just like the real thing".
Comparing virtual and physical systems is like comparing apples and apples, not apples and oranges: while apples are mostly interchangeable, they is certainly variation between them. Some apples are best for eating, some are better for making sauce, some are pie material, and some are best for fermenting cider. The type you select depends on what you want to cook. The difference between physical and virtual hardware is similar: they can be used as replacements for each other to some extent, but the connoisseur can make much better use of both by looking at the differences.
This post goes through some of the important fundamental ways that virtual hardware is different from physical hardware.
No Permanent Existence
Virtual platforms do not have a constant existence. They pop in and out of (virtual) reality as needed. Each time a piece of virtual hardware is started, it has a pristine state. Any changes made to its memory, disks, EEPROMS, and other storage the last time it was used will be gone. On hardware, cleaning out changes from one use of it to the next is an explicit step. On virtual hardware, remembering the changes is an explicit step, performed by saving the state of virtual disks and other persistent storage before quitting the virtual platform. Then, the user can elect to make use of the changes the next time the platform is started.
The fact that a virtual platform only exists while it is in use means that a single piece of hardware (the host laptop, desktop, or server running the virtual platform hardware) can take on many different roles over time. Rather than having a lab with ten different types of boards, there is a single general computer executing virtual platforms as needed to provide the boards required.
The way that persistent state is handled also means that we can separate the contents of memory and disks from their actual storage on the board. A single piece of virtual hardware can be equipped with a variety of software loads just by changing which file is used to populate the disks and memories of the virtual platform target when it is created.
The occasional existence of a virtual platform also means that it does not wear out over time, something I discussed previously.
System as Document
Since a virtual system is a piece of software, it makes sense that it can save what it works on as a document, just like a word processor saves this text as I am working on it. In Simics, this is called checkpointing and lets you save the entire state of the system to a document. That state can later be picked up and the execution continued seamlessly from the same point.
Checkpoints offer an efficient way to deal with testing of embedded systems. On hardwqare systems, a power cycle is typically applied between each successive test. Resetting the system in that way is an effective (if not efficient) way to isolate tests and avoid the accumulation of (bad) state in the system. With a virtual system, this can be achieved using checkpoints. Instead of cycling power and rebooting, we just pick up a checkpoint of a booted and loaded target system and go from there.
Using a checkpoint each time ensures that a test cannot contaminate any permanent storage – any changes to the target system are discarded when the virtual platform terminates. Using a checkpoint is much quicker than running through the boot each time.
Checkpoints enable the tests to be run in parallel. A virtual platform can be instantiated any number of times, and when tests are independent, it makes perfect sense to run them in parallel on a cluster of host machines. Indeed, parallel simulation can cut the time needed for testing a new software version significantly compared to using a limited number of physical boards. The use of Simics on clusters for running test cases in parallel is common practice (see for example the Archer system). In particular for aerospace systems, this has been shown to cut regression test time dramatically compared to hardware setups, enabling more testing and more frequent testing, preventing errors from creeping back into a system.
Checkpoints can also be used to facilitate bug reporting (as previously discussed).
A virtual platform lives in virtual time, which make them different from run-time IT virtualization solutions that try to create something that looks like a regular server to the outside world.
To retain control and determinism, the time in the virtual platform does not try to keep pace with the real world. If you think about checkpointing, you realize that in order to reexecute deterministically, you absolutely have to keep time inside the virtual machine as part of the checkpoint. Each time the checkpoint is opened, time is set to the time the checkpoint was taken.
The advance of time inside the virtual system is going to be uneven, as observed from the outside. Sometimes the virtual system is much faster than real time (when lightly loaded Simics skips ahead in time), sometimes much slower, sometimes time stands still (when paused), and sometimes it goes backwards (when using reverse execution). This means that external tools looking at the virtual system should not check timeouts and deadlines in host time, but use the virtual time. There are several mechanisms in Simics to allow external tools to peek at the virtual time.
As always, there is an exception to this rule: when a virtual platform is used as part of a hardware-in-the-loop test setup, the progress of time needs to be kept very strictly in sync. In Simics, we have what is called the "real time mode", which slows Simics down as needed to keep time advancing at the same rate as in the surround physical system.
Simics can execute much faster than real time when the target system is not loaded. Thanks to the architecture of Simics, Simics knows when there is nothing going on inside the target system, and skips ahead in virtual time in a single step. When a target is just sitting there idling, Simics can run it many times faster than physical reality (depending on many factors this can get into 100x territory). This can be exploited to perform long-running simulations of some types of workloads. For example, you could simulate months or even years of a space mission, as their control computers tend to be slow and mostly idle, making sure to test what happens as the system stays on and accumulates state over time.
So, in summary, virtual hardware is like physical hardware in some ways, and unlike physical hardware in other ways. Understanding the difference is key to make the best use of your development systems, virtual and physical.