The folks at ARM have a bit of a chicken-and-egg problem that any creator of a new CPU instruction set is likely to face. How exactly do they enable the creation of ARMv8-compatible chips, devices, drivers, and software without any functioning hardware available for testing? More acutely, how do they make sure the transition to the 64-bit ARMv8 instruction set happens quickly enough to keep up with the crazy-short design cycles of today’s tech gear?
The answer, it turns out, is for ARM to build its very own reference platform, complete with a six-core custom SoC. That platform is dubbed Juno, and ARM says it’s just now becoming available to customers who could make use of that sort of thing—think SoC makers, kernel and hypervisor developers, the creators of driver software, and the low-level programmers who build things like game engines.
The news of an ARMv8 reference platform’s first availability in mid-2014 may seem surprising given the tremendous momentum ARM’s 64-bit ISA already appears to have in multiple markets. After all, Apple has been shipping 64-bit hardware for some time now, and Google announced the Developer Preview of the 64-bit Android L release just last week at its I/O conference. Still, until Juno came along, the only ARMv8-compatible hardware out there was Apple’s custom SoCs, which are closed off from the Android ecosystem, and an early server chip from Applied Micro that’s not publicly available. Both use custom CPU cores. Juno, by contrast, is built from ARM’s own licensable components, specifically those from the company’s suite of mobile IP. Any firm with the wherewithal to pay the price of entry can now buy a Juno development board from ARM and test with working hardware.
The Juno development board. Source: ARM.
Both the Juno motherboard, pictured above, and the SoC that powers it were created by ARM. They’re intended to be functionally correct and a good representation of a potential mobile system, but like many development platforms, Juno isn’t meant to deliver best-in-class performance or efficiency.
Logical block diagram of the Juno system on a chip. Source: ARM.
Still, it’s interesting to see how ARM would go about building an SoC comprised of its own IP. In some respects, I think Juno’s component mix may be more sensible than the one we’ll see in end-product chips from ARM’s partners. For instance, Juno combines two relatively large (for a phone or tablet) Cortex-A57 CPU cores with four lightweight Cortex-A53 cores. This contingent of big and little cores probably better fits consumer usage patterns than the eight-core configs currently on the market.
Juno also includes ARM’s own Mali-T624 graphics processor, the mobile-focused CCI-400 uncore, dual DDR3 memory controllers, and a Cortex-M3 “system controller” block that handles SoC-level power management. Not shown in the diagram above is a low-bandwidth interface that can connect to an external FPGA logic tile. The FPGA can be programmed to emulate external devices, allowing another degree of hardware flexibility for testing.
One of the first fruits of Juno’s existence comes from the the folks at Linaro, who help create much of the core open-source software for ARM-based devices. (Linaro is a not-for-profit organization supported by ARM and a range of ARM partners; Qualcomm and MediaTek are the most recent to sign on.) Linaro has had the Juno board in its hands for “a little over a month” and is today announcing the release of a port of Google’s Android Open Source Project to the 64-bit ARM ISA. This port is essentially an early-access version of Android L for 64-bit hardware. Along with Juno, it should enable SoC and device makers to begin building and customizing their solutions right away, before their own SoCs are etched into silicon.
To give one example of the sort of thing Linaro contributes to the Android ecosystem, this first 64-bit release from Linaro already supports most optimal form of ARM’s big.LITTLE power-management scheme, known as Global Task Scheduling. In theory, GTS is the most efficient means of distributing tasks to the appropriate cores in order to maximize power efficiency, but it’s also a fairly sophisticated form of asymmetric multiprocessing that requires the explicit support of the Linux task scheduler. We’re talking about modifying a low-level core Linux kernel component, so it’s a non-trivial affair. Linaro has built GTS support into its first 64-bit release, and device makers can choose to adopt it if they wish. It’s possible Linaro’s changes could be incorporated to “upstream” projects like AOSP or even the core Linux kernel at some point in the future.
Linaro does monthly software releases, so this first 64-bit implementation of AOSP will be getting more refinements along the way as the developers get more time with Juno and the Android L preview. The folks at Linaro are eyeing OpenSSL and the cryptography instructions in ARMv8 as a potential target for optimizations. Adding hardware encryption support could boost performance and improve battery life across a broad swath of the Android ecosystem.
Meanwhile, ARM itself is using Juno in the development of drivers for its Mali series of GPUs.
I can’t help but think Juno would also, ahem, be an interesting platform for, say, a hardware review site to use in testing ARM’s 64-bit CPU cores against the competition. Just, you know, throwing that out there. Who knows what might happen next?