ARM Unveils New Architecture for Automotive

The need to handle the growing load of disparate software including contributed codes by OEMs is, in turn, pressuring Tier 1 modular vendors such as Bosch or Continental, said York. Their modules are now expected to run, on the same ECU, new contributed codes from OEMs alongside existing software -- some of which are safety-critical applications -- "without mucking everything up," said York.

Contributed codes are all over the map. Their spectrum ranges from safety-related features such as braking to less critical functions like window wipers, seat positioning, and new graphics on the human-machine interface. The key for the successful integration of such diverse software is the microprocessor's ability to make a clear partition separating one app from another.

Leading software vendors such as Green Hills Software already offer secure virtualization through a well proven hypervisor layer, York told us. To date, however, none had developed hardware support for virtualization. With hardware support, "you no longer need to rely on writing complex software, which is often a very expensive solution."

The fundamentals of the ARMv8-R architecture are consistent with the ARMv8-A, according to York. While the previously announced ARMv8-A architecture is focused more on high performance, the ARMv8-R zeroes in on real-time processing. The new architecture, for the time being, only supports 32-bit register, as the company does not see, for now, the need for 64-bit among real-time embedded applications, said York. The new ARMv8-R will maintain backward compatibility with ARMv7-R ARM and Thumb instruction sets.

Ecosystem support for the ARMv8-R architecture is anticipated in a number of operating system products including Green Hills Software's Integrity, Nucleus from Mentor Graphics, and T-Kernel from eSOL, according to ARM. These integrated hardware and software solutions will be capable of supporting stringent automotive and industrial interoperability and safety standards, including AUTOSAR, ISO 26262, and IEC 61508.

ARM will be disclosing details of the new architecture at the upcoming event, ARM TechCon, in Santa Clara, Calif., that starts Tuesday, Oct. 29.

Well I'd be surprised if those PowerPCs had an interrupt latency of ~10 cycles. Cortex-R cores are used in hard realtime tasks like flying the heads of a HD. Typically when you have caches latencies go up to hundreds of cycles. This is due to having many outstanding cache misses and writebacks in flight - you can't just drop those on an interrupt as you end up in an inconsistent state...

All new cores like Cortex-A7, A12 and A15 have division. Cortex-A8/A9 don't have divide as division was introduced well after they were finished. I agree it's not ideal but then again around 10 years ago, when I talked to an ARM hardware guy and asked how fast he could implement division on something like ARM11, his answer was "about 40 cycles". I then said "well my software division easily beats that with an average time below 30 cycles, so don't even bother". It seems that after the introduction of Cortex-M3 with its amazingly fast division hardware designers made division fast enough on higher-end cores as well!

The issue with running an RTOS on an -A core is that interrupt latency is much higher on fast OoO cores with large caches. So you lose the R in RTOS. The -R cores have special features to keep interrupt latency low (although to get the lowest interrupt latency you have to use an -M core).

Actually, I'd say no. There are a lot of CPUs arround with cache which are used in realtime enviroments (like all the automotive PowerPCs).

All Cortex-A cores since A15 do have integer divide. The latest QC and Apple cores do have divide as well.

The thing is, Cortex-R4 has it, but e.g. ZYNQ Cortex-A9 does not have it as it is "optional".

In an ARMv7-A implementation that does not include the Virtualization Extensions, the implementation of SDIV and UDIV in both instruction sets is OPTIONAL, but the architecture permits an ARMv7-A implementation to not implement SDIV and UDIV.

So what? I really wonder, what goes on in the brains of architecture developers (and as it is optional: implementers) :-(

The R variant of the architecture has always been something of a middle ground, with some -M features and some -A features. That's just what the RTOS people seem to need.

If you want 32 registers then you do want 64-bit but use 32-bit pointers to avoid the overhead of 64-bit pointers. For x64 there is already a Linux ABI with 32-bit pointers, so I bet there will be one for ARM64 as well.

The issue with running an RTOS on an -A core is that interrupt latency is much higher on fast OoO cores with large caches. So you lose the R in RTOS. The -R cores have special features to keep interrupt latency low (although to get the lowest interrupt latency you have to use an -M core).

All Cortex-A cores since A15 do have integer divide. The latest QC and Apple cores do have divide as well.

Ok, reading this document shows really some improvements over v7R.But it again makes me wonder why ARM differs -A and -R but now they mix -A and -R with the v8-R only that there is no 64bit support (which I do not miss) and no support for the new ISA with 32 registers (which I miss).Granted, todays feature rich (overloaded?) OSes will not run on a R or M CPU, but on the other hand, an RTOS very well runs on an A one.

I really wonder: Do the ARM ISA developers talk to (RT)OS designers asking what they think an ISA needs? I mean, how come an Cortex-A CPU does not have integer divide? (Ok, now going off-topic...)

So lets wait for the first dual-core v8-R (no more Cortex I guess) CPU.

This is the v8 version of the v7-R architecture. So it is indeed compatible with existing cores like Cortex-R4 but adds new features as well, such as the Hypervisor and support for running Linux. Note v8-R is not 64-bit.