ARM v8-R launch focuses on safety applications

ARM has launched the -R version of its v8 architecture, targeting applications in automotive and industrial systems where safety is a primary concern. Building in support for virtual memory as well as operating-system virtualisation, the company also has its eyes on a new generation of industrial microcontrollers that run Linux and similar operating systems.

Richard York, director of product marketing for embedded processors at ARM, said: “The first products are in development and those first products have a whole raft of safety features in them as they are aimed at applications such as braking and powertrain.”

The hypervizor support will enable multiple operating systems to run side by side, allowing systems that used to employ two or more slower processors to coexist on one with few changes to the applications code. This is a trend that is picking up pace in automotive and industrial systems.

“People in automotive are consolidating Autosar applications,” said Chris Turner, senior product marketing manager at ARM, adding that in its simplest form the v8-R architecture lends itself to industrial control applications that use Linux for much of their operation but need a real-time OS layer for tasks that need determinism.

“We think this architecture may unlock a whole new raft of low-end microcontrollers that can run Linux alongside real-time operating systems. Most Linuxes don’t have an underlying real-time mode: the hypervizor can help provide this support. And Cortex-M doesn’t run operating systems that have virtual memory.

“We see a general-purpose mass market may arise, one that hasn’t existed up to now,” Turner added.

32bit focus

Unlike the v8-A architecture employed by the Cortex-A53 and A57 launched at last year’s ARM TechCon, the v8-R is a 32bit-only architecture. “These designs are still some way below 4Gbyte,” said Turner. “If they are in automotive, they are probably running from embedded flash. You have maybe half a megabyte before it starts to dominate die area. If it’s off-chip, it could be a few megabytes. People running Linux might have up to 16Mbyte of external DDR [DRAM]. And by embedded standards these are relatively large systems.”

For the new architecture, ARM has changed the interrupt structure and memory-protection subsystem to better handle hypervizor-based environments.

Turner said: “With v8-R, we have brought the interrupt controller closer to the processor and introduced new system registers that are used to program the interrupt controller. This and other changes we have made will make for lower interrupt latency, outperforming our current version 7 processors.”

Fast switch for hypervizor

To account for the presence of a hypervizor where an interrupt may trap into a different guest operating system than the one running when the interrupt arrives, ARM has implemented a fast-context mechanism to move to and from hypervizor mode. “These modes have their own registers similar to those in v8-A but they are different in R to better support real-time demands,” said Turner.

ARM’s processors for real-time applications have for some years offered a memory protection unit (MPU) to prevent tasks in the same address space overwriting each others’ data. In the process nodes that were commonly used for these applications when the MPU first appeared, die area was more precious and there was greater sensitivity to the potential for complex logic to slow down memory accesses.

One of the consequences was that the sizes of protected regions had to be multiples of their base address. “For example, a 32Kbyte region had to sit on a 32Kbyte boundary, which could be a little cumbersome,” Turner said. “When people switch contexts, they have to do a lot of offline calculations to work out how to reprogram the unit to get the protection they need.

“What we found is that for [process] technologies that have appeared since 90nm, the access and cycle time challenges have moved elsewhere in the pipeline. So we revised how we do the MPU programming,” Turner explained. “We have taken that limitation away and now any region can start on any base address to a granularity of 64bit. That will take hundreds of cycles away from a context switch, based on some of the designs we have seen.”

Watchdog interrupts

A further change to the interrupt handling has come with the addition of a system-error pin in addition to the traditional interrupt pins. “This can create an asynchronous abort. There is already a synchronous abort that triggers if you get something like an undefined instruction or a memory-protection fault,” Turner explained. “The purpose of this is for safety-related applications where you may connect the pin to something like a watchdog. You can use the other interrupt pins for regular work and then use the system-error pin for a safety-related fault.

“One way of using this would be in the interconnect if you are doing error-checking across the fabric, as well as for watchdogs for platform-related errors. It makes a difference for functional-safety considerations.”

The interrupt controller will support virtualization of interrupts, primarily through paravirtualization. “We expect most people will opt for some form of paravirtualization where they make their own tweaks to the operating system rather than full virtualization. In this environment, it’s more cooperative,” said Turner.

Linux support

As well as the MPU, v8-R processors can include a memory-management unit (MMU) suitable for Linux and similar operating systems. In effect, the two memory units run side by side, so that a flat-memory RTOS has its memory accesses go through the MPU but they are not further translated by the MMU. The hypervizor has access to a stage-two protection unit “to ensure sandboxing of the different virtual machines”.

This arrangement is different to that used in v8-A where there can be two levels of address translation, which would potentially introduce non-deterministic memory accesses for real-time applications. So the architecture employs two layers of protection but only one translation layer, which is further restricted to virtual-memory operating systems.

Security cooperation

Another change compared to the v8-A is around security. “We are not supporting Trustzone in this architecture. Although they are often confused, safety and security are two different topics. This architecture is very much targeted to safety-related applications, which are becoming dominant in industrial circles. We think most people will agree with our approach, in which we see the security element being outside the main CPU.

“Once you are into the main CPU you want safety but you are doing what you are meant to be doing,” said Turner, adding that in coming automotive and industrial architectures security functions such as secure boot and network monitoring will be handled by a separate processor core. “We do expect that the security processor will probably collaborate with the hypervizor, so that certain processes can’t be switched in unless the security processor has approved it.”

Multicore is a likely direction for v8-R, said Turner: “We do expect that this architecture will be delivering multiple processors that operate in lock-step, as they do with existing generations.”

Although not designed for any specific process nodes, ARM expects 55nm and 40nm processes to be important for cores based on the v8-R architecture. “This is governed mainly by the availability of embedded flash that is qualified to industrial conditions,” Turner explained. “There will eventually be 28nm for sure.”