ARM v8-R architecture revealed
ARM has released details of its v8-R architecture, intended to allow multiple operating systems to run on one core in hard real-time environments.
“This architecture can cope with the increasing complexity we are seeing in automotive and factory automation, where people are consolidating software onto the same processor,” Chris Turner, product marketing manager at ARM, told Electronics Weekly. “Some of this code might be concerned with functional safety, where there is a reliance on software to do the right thing, even in the presence of random faults, like alpha particles, glitches and aging; and systematic faults like bugs.”
This is ARM’s second version 8 architecture announcement. The first, v8-A, was two years ago for its Cortex-A series of application processors, when it added 64bit instructions. So far there has been no mention of v8 for its Cortex-M microcontroller processors, which remain at version 7. Cortex-R cores are on SoCs in chips for so-called ‘deeply-embedded’ applications, like chips controlling hard-drive read-head servos and car braking systems. Processing power in R cores overlaps low-end Cortex-A cores, while they retain the cycle-counting determinism of -M cores.
By the way: “We are not precluding 64bit in v8-R. The application space does not need it today,” said Turner.
The biggest change from v7-R to v8-R is the addition of hardware support for a hypervisor.
A hypervisor is a small amount of code that schedules programmes (or operating systems) and allocates memory in a way that completely isolates those programmes. As a non-real-time example: hypervisors are used to allow banking applications to run alongside trivial applications on phones. They also allow legacy programmes to be combined on a core without changes.
“You can view this as a form of multi-tasking. Each task thinks it is running in its own machine, but actually it is being scheduled by the hypervisor. If it is architected in the right way, it can support multiple guest operating systems, tasks and applications – with fast real-time response,” said Turner. “A hypervisor has to push and pull the stack, and re-programme memory protection systems. This is all made easier and faster by having the right hardware support.”
Automotive is a particular target, he points out, because the number of processors in a vehicle is proliferating and car makers want to stop the rise by making cores do more than one thing. When these are ‘white box’ (can crash) and ‘back box’ (fail safe), something has to guarantee code separation.
The v8-R hypervisor can handle many code entities, according to Turner, but “in practice, you wouldn’t expect more than two or three. Typical you are in and out of a hypervisor for 10 or 20µs every 100ms. Real-time services typically don’t take much processing, but have to be done on-time every time”.
Other changes in v8-R include an evolution of v7 language support, for the 2011 edition of ANSI C – particularly behaviour for interlocking memories between processes, said Turner, and the latest IEEE floating point standard. There will be a memory management unit, only offered in Cortex-A to date, and a memory protection unit using similar technology the one in Coretx-A15.
Backward compatibility will be maintained with v7-R and Thumb instruction sets.
No v8-R intellectual property for cores will be available for a while. “We are not saying when it will be available, I wouldn’t expect anything for a year or so,” said Turner. However a v8-R specification is available to those signing a secrecy agreement with ARM.
Why such an early announcement?
“Target customers move on long project cycles. A car [started now] might not appear in showrooms until after 2020.
Ahardware and software support ecosystem for v8-R is expected to be announced next week at ARM TechCon.
This ARM v8-R architecture white paper gives more details.