By Jakob Engblom
We just released a new Simics feature, the QSP (Quick-Start Platform). This is a synthetic simulation-only Simics target machine that is included with the Simics base product. QSP provides every user with a useful Simics target that allows you to immediately start using Simics and reap the benefits of simulation for software development, without waiting for a target model to be ready. It provides a quick way to realize our old Simics slogan: "Resistance is Futile, you will be Simulated."
With QSP, we provide a shortcut by offering a ready-to-use integration of a model and target software stack that can be used to do application-level development from the moment a user receives Simics. QSP also makes simulation features like checkpointing, reverse execution, unintrusive debug, repeatability, automation, and scripting easily available for application developers without having to first setup an OS and select a target machine.
A key use case for QSP is developing user-level application software. QSP presents an application developer with an operating system on top of a certain architecture, with a set of functions available in the hardware and supported by the software stack. All application software is compiled to the target architecture, not to the host, and application binaries from a real target should run on the QSP, provided that the OS APIs in the QSP are sufficient.
Let's go over some examples of how QSP can be configured and used.
Our first example will be Linux on a dual-core Power Architecture machine with Ethernet and serial, as shown in the picture below.
This type of target would be used to run a networked application. By instantiating multiple QSPs in a single simulation, the network application can be tested with communication between the boards. It does not matter which Ethernet adapter is used or the precise nature of the board, as long as the application can run with two threads tied to a core each and communicate over Ethernet to its peer.
Thanks to Simics repeatability and control capabilities, network scenarios involving all the machines can be perfectly replicated, analyzed, and debugged, across the entire system. An instantaneous system state, including traffic sessions in progress, can be saved as Simics checkpoints, allowing the developer to come back later to a particular point in the execution. Checkpoints can also be used to capture and communicate bugs between team members, replacing the tedious process of describing system setups in bug reporting systems. The Simics system-level debugger allows source-code debugging on all target systems at once, at the application level, with synchronous stepping of the entire system, not just an application at a time. Reverse execution and reverse debugging can be applied to the entire system, following the flow of control and packets between the machines backwards in time. Simics Analyzer makes it easy to see how programs on both sides of the network connection wait for data and get activated.
Another crucial function is using a flash disk. In the picture above, we see an ARM machine with a flash disk running VxWorks. A serial setup is added to have an interactive connection to the target. This setup would allow a programmer to develop and test software interacting with a flash-based file system, without caring about the make and model of the flash memory unit, or how to configure a driver stack (for a real flash-based system you tend to need to know the type of the flash to correctly configure the OS to drive it, while with the QSP, there is just a single type of flash and the driver configuration is given). The QSP flash disk is also much faster than a real one, as there is no need to wait for contents to stabilize after a write.
In Simics, saving and restoring multiple versions of the flash disk contents is trivial. Since disk changes are handled as diffs, any bad operations can be easily undone by restarting the simulation session (which discards all changes). They can also be interactively undone by using reverse execution in the simulation session.
QSP was designed with multicore in mind, and it offers a more flexible target in terms of the number of cores available in hardware than any physical ARM or Power Architecture system available today (with the exception of IBM pSeries servers). As illustrated in the picture above, this can be used to test the scaling of and debug the behavior of multithreaded multicore software, easily varying core counts to see what happens. With Simics repeatability and reverse execution and reverse debugging, concurrency bugs are much easier to find and fix than when using physical hardware.
At this point, it is worth remembering that application binaries developed on a QSP will run on real machines too. Indeed, a key value of using QSP for application development is that the same cross-build tools and the same OS API and ABI are used on the physical target. Thus, the application binaries compiled for and tested on a QSP will run unchanged on a physical target (with the same OS and architecture). If the application uses third-party binary-only libraries, these can be used as-is. In this way, QSP reduces the distance between the development environment and the production environment, compared to using host-based development.
There is a real and relevant difference between Linux on Power and Linux on ARM and Linux on an x86 host. With QSP you find the target-related issues during application development rather than much later at hardware-software integration. If Simics is also used to model a real board before physical hardware appears, integration issues can even be found and resolved before the actual target exists.
Above, we show an example of how QSP can be used to shorten the development time and time to market for a system based on custom hardware. The eventual goal of the project is to have the real OS running on a model of the actual physical hardware board used in a system, and after that on the physical board itself. With QSP configured with the relevant functions, application development can start concurrently with the development of the model of the physical platform. Once the platform model is finished and the OS runs on it, the application is available for execution and integration test. Without QSP, we would have had to wait until the virtual platform was complete enough to use before doing application development.
QSP is also a great teaching platform. It is an obvious candidate for setups like the one presented in my previous blog on teaching networking with Simics - you want plenty of Ethernet ports and a certain OS, along with ease of use and ease of portability across target architectures. The QSP design is a natural match for such use cases. QSP is also perfect for university-level OS courses. It reminds me of a course that I used to teach where students were given the task to develop an OS kernel from scratch. In QSP, you have all the relevant interesting behaviors such as interrupts from devices, timers, multicore, etc., but none of the arbitrary complexities of real hardware platforms. For example, configuring an i8254 interrupt controller to get serial port interrupts is pretty complex, distracting students from the core subject material of how an OS kernel works.
This blog post has really only scratched the surface of what QSP can be used for. It offers a very quick way to get going with Simics simulation, and to apply the benefits of simulation for software developers for all application development - regardless of whether there is an actual platform model available for the actual target hardware.
For additional information from Wind River, visit us on Facebook.