There is a new post at my Wind River blog, about the design and technical contents of the new Simics Quick Start Platforms, more widely known as the QSP. The blog describes the virtual-only hardware that forms part of the QSP, and how it was designed. It is interesting to note that the hardware ended up a bit more complex that I initially thought it would be, since an ideal virtual platform should be very simple. Right? Turns out an OS complicates things.
Basically, today’s operating systems contain many structures and design patterns for device drivers that have evolved together with hardware over the years. Thus, the least overall effort when taking virtual hardware design and driver development into account is typically not to make a totally green field design, but rather to look at what exists and simplify it. The Wind River blog post contains several examples, such as having transmit delays in serial ports and Ethernet MACs, along with the requisite transmit interrupts. This works much more easily with the given structure of Ethernet and serial drivers in general in OSes like VxWorks and Linux.
There are many other concepts around that are more or less similar to the QSP idea.
Several “Android simulators” out there start with some standard platform and add virtual-only devices that are just like QSP devices. However, these systems leave the interrupt controller and other common parts as they are from some real system, they are not synthetic all the way through. The end goal is pretty similar though, being the development of application code on a virtual platform without having to create a perfect model of a particular real phone.
Carbon Design Systems recently announced something they called the CPAK, Carbon Performance Analysis Kit, which is basically a core subsystem of an ARM-based SoC that is capable of running Linux. With this, Carbon customers can immediately start to do performance analysis of applications on Linux on various ARM processors, without first building a model of their own ASIC. It is not very clear what is included in a CPAK, but it seems mostly be a processor core, caches, and memory. I assume there are also interrupt controllers and timers, serial ports, and maybe other IO.
It is interesting to compare and contrast the Simics QSP and the Carbon CPAK. Where the goal of a QSP is to be purely virtual and not model any real hardware, the goal of the CPAK is to be very true to the real hardware. The use of compiled RTL models of processor cores, cache controllers, and bus systems is a key part of the value, as this provides a true view of the performance as it will be in a real hardware system. This means that while a single QSP can cover the needs for all ARM Cortex-A series processors, CPAKs will exist for each particular core. It also means that it is hard to make a CPAK more flexible than hardware, since it is by design limited to the scaling of existing cache coherency systems. Both ideas have merit, and both are needed, but for different users at different stages of the system design cycle.