ARM v8-R will be used for the next generation of ARM R cores that are currently used for ASIC designs with automotive and large industrial customers. Unlike the 64bit V8-A architecture for applications processors such as the Cortex-A53 and A57 and it will be 32bits, but it adds the same ability to run Linux and Android ‘out of the box’ alongside security and virtualization enhancements. Both of these tackle the issue of the memory management unit (MMU).
“Over the last two years we have been planning how to apply the new technology to embedded applications,” said Richard York, director of embedded processors at ARM. “Talking to people in the automotive and industrial markets, they have big software problems that microcontrollers don’t help them solve, such as different levels of safety, combining rich operating systems with real time operating systems, legacy software and software form lots of different sources”
The A8-A architecture was ARM’s first move into 64bit, but A8-R will not follow yet. It uses the AArch32 exception model that is compatible with that used in ARMv7-R and executes the ARM32 and T32 (Thumb) instruction sets sa well as using the NEON extensions and existing SIMD constructs.
“What we are doing is not 64bit initially because the market doesn’t want it,” said York. “Systems are not hitting the 4Gbyte memory limit and there are gaps in the architecture. But we have 64bit in mind because at some point they will want it. It’s not a question of if but when.”
Cores based on the A8-R architecture will be announced next year, with silicon from partners in the second half of 2015. The first devices will emerge for the industrial market even though the main focus is automotive. “The main competition is proprietary architectures,” said York. “The people we are talking to are using [Freescale] PowerPC, [Renesas] SH, [Infineon] Tricore or [Renesas] V850.”
The MMU will be 100% architecturally identical to the A8 version to run the wide range of software being developed for mobile applications. Underneath that, virtualization hardware will allow hypervisors to run unmodified on the core with only one level of translation to support both mainstream operating systems such as Android alongside and RTOS.
In order to maintain determinism, the stage-2 memory translation scheme of the Av8-R architecture differs from that of ARMv8-A. A conventional scheme would support translation at stage-2 so that every memory address would be translated to a new address by a second stage of translation.
Instead, the stage-2 scheme in the Av8-R architecture only supports protection, which means the intermediate physical address (IPA) generated by a given guest OS is always the same as the final Physical Address (PA). The Memory Protection Unit (MPU) is register-based and tightly coupled to the processor, providing fast, deterministic responses and so avoids failures in hard real-time systems when an interrupt is not serviced in the required time due to the overhead of page-table walks required to refill the TLB in the event of a cache miss.
This stage-2 MPU ensures the integrity of the hypervisor software and isolates each of the guest operating systems to its own physical address space, controlling whether or not a particular OS can assess any given peripheral or memory location.
ARM is working closely with Green Hills Systems and Sysgo on hypervisors that are optimized for A8R cores. “I think in this embedded world we could imagine people wanting to tweak the RTOS [for A8R] and that makes sense,” he said. However, the architecture does not include the TrustZone security that has been used in mobile devices.