The retargettable embedded system emulator architecture
PEMU makes it possible to model any embedded system on the software developer's desktop so accurately that the software under development cannot tell the difference between the simulation and the real system hardware: binaries run unchanged, even operating systems, device drivers and so on. It allows software developers to escape the tyranny of having to test and debug software on hardware, which is hard to use and expensive.
More importantly, hardware often does not exist when it is under development. However, a model can easily be created early to allow software development to be started months ahead of hardware availability, with clear time-to-market advantages.
As part of the edit-compile-debug loop, a software engineer can use the model to run and debug any software for an embedded system.
In short, PEMU will give the software developer all the advantages of speed and accuracy of real hardware, without the disadvantages of cost, availability and unwieldiness.
Architectural design of a system has historically been a rather ad hoc process, relying on rules of thumb and on C programs that attempt to analyze some important performance attributes of the system. PEMU allows a virtual prototype of the system to be created which can be reconfigured to investigate the parameters, such as bus widths or queue depths that need to be analyzed. Instead of using artificial data of unknown fidelity to drive this process, the actual software that will ship on the system (or an earlier version) is used so that the architecture is analyzed under much more realistic conditions.
PEMU can be interfaced to real world network or I/O traffic, so it is possible to use existing traffic generators to stress the new architecture.
The virtual prototype can be handed to the software development group long before hardware design is complete. Software development can start many months earlier. Indeed, once the basic architectural decisions are final, software development can even be overlapped while the last details of the architecture are finalized.
PEMU has a powerful checkpoint/restart mechanism which means that it is possible to partially run tests, for example to boot a system, and then restart many examples each injected with a different fault. Judicious use of this capability means that running a full suite of tests often takes less time than on the hardware.
Unlike real hardware, PEMU is fully deterministic. Running the same test, such as generated network traffic traces, will always produce the same outcome. If a problem is detected it is easy to reproduce by simply re-running the test.
Since PEMU runs on inexpensive off-the-shelf PCs, enormous savings of capital equipment are possible. Not having enough hardware for testing is a thing of the past. Each engineer can have their own target system at their desk without any additional hardware cost.
Once a product is modeled in PEMU there are many places after development and test where PEMU can be used, even once the product is shipping in production. PEMU means that any computer can be used to mimic any product from the catalog. Or even several of them networked together.
Training, both internal and external, can be done using PCs. This avoids the logistical complications of ensuring that enough real hardware is available in the right locations for the training, and saving the expense of buying training hardware. The hardware does not even need to be shipping. Training can be done on a product before it is available, or during the early phase when expensive pre-production units would otherwise be required.
Similarly, field engineers can use their laptops to reproduce problems in the field and then mail them back to engineering for fixing. This approach immediately removes the problem of the field reporting problems that engineering is unable to reproduce and so fix. PEMU checkpointing and determinism ensures that once a test case is setup, it can be rerun any number of times.
Hardware verification is getting increasingly complex as more and more functionality migrates into the software of a system. It is no longer sufficient to test the hardware under development with a few carefully crafted test vectors. Rather, the full software stack must be used to exercise the hardware in a real world environment. PEMU provides a fast emulation of an embedded system, including the actual shipping binary code, so that real-world interactions between hardware and software can be captured.
By using the infrastructure throughout the development process, productivity is increased. It is possible to run more tests in the less time, resulting in a higher quality system.
(To be continued)
(C)2005 All rights reserved by Stanley Huang | Page visited for times