ARM big.LITTLE Virtual Platforms

You have probably heard something about ARM’s big.LITTLE architecture. This links a Cortex-A15 multi-core CPU with a Cortex-A7 CPU. The A15 is a high-performance processor and the A7 is a very low power processor. The basic idea is that when high-performance is required (playing a graphical video game on your smartphone, for example) then the A15 is brought into play and when high-performance isn’t needed (during a phone-call, for example) then the A7 is used. This gives the best of both worlds, a processor with high peak performance and very low average power.

It is worth noting that since the processor is often only a small part of the system, that running slowly, and thus keeping the whole system powered up for longer, is not always optimal. In some systems it is better to “race-to-halt” and run as fast as possible and then power-down the whole system until the next burst of activity.

Whether a task runs on A15 or A7 is not under control of the task, but instead it is handled dynamically by “task migration software” running underneath the operating system in a virtualization layer. So there is application software running on top of an operating system like Android running on top of a hypervisor, running on top of a multicore chip with two different performance levels. For the first time, application software at the top of the stack can have a major potential impact on power consumption (aka battery life).

The obvious answer to how to write software for any complex hardware is to use a virtual platform. The problem, as always, is availability of models. Synopsys have released a Virtualizer Development Kit (VDK) for this platform, incorporating high-speed models of the Cortex CPUs along with models of popular peripherals such as keyboard, touchscreen and ethernet. In fact they have created sort of starter kits which are virtual versions of ARM reference boards (which are not yet available in any case).

These virtual platform models are integrated with all the popular multi-core debuggers (don’t try and persuade a software engineer she can’t have the debugger she is used to) and additional instrumentation so that you can see what software is running on which core. Different systems might want different policies on this, from a high-performance system that primarily runs on A15 (big) and really only runs on A7 (little) when it is pretty much idle, to a system that runs mainly on A7 and only switches reluctantly to A15 when the A7 seems to be out of juice.

In multicore environments, virtual platforms offer some major advantages over hardware reference boards: they are deterministic and the whole system can be frozen. With multicore hardware, there is no guarantee that a bug will re-occur if the program is re-run. And if one core hits a breakpoint there is a delay before other cores can halt (“limited skid breakpoints”). With a virtual platform, rerunning the software with the same inputs will produce the same outputs, and reproduce the same bugs. And if you hit a breakpoint then all cores can be stopped to allow an in depth examination of the innards of what is going on.

The platform also allows a coarse level of power analysis, looking at the different power levels for each device depending on its state (so an LCD screen might be bright, dim or off).