Arm Announces Cortex-R82: First 64-bit Real Time Processor
by Andrei Frumusanu on September 3, 2020 9:00 AM EST
Arm is known for its Cortex range of processors in mobile devices, however the mainstream Cortex-A series of CPUs which are used as the primary processing units of devices aren’t the only CPUs which the company offers. Alongside the microcontroller-grade Cortex-M CPU portfolio, Arm also offers the Cortex-R range of “real-time” processors which are used in high-performance real-time applications. The last time we talked about a Cortex-R product was the R8 release back in 2016. Back then, the company proposed the R8 to be extensively used in 5G connectivity solutions inside of modem subsystems.
Another large market for the R-series is storage solutions, with the Cortex-R processors being used in HDD and SSD controllers as the main processing elements.
Today, Arm is expanding its R-series portfolio by introducing the new Cortex-R82, representing the company’s first 64-bit Armv8-R architecture processor IP, meaning it’s the first 64-bit real-time processor from the company.
To date, previous generation R processors were based on the predecessor Armv7-R or ArmV8-R 32-bit architecture, such as the Cortex-R52. This was for years still fine and sufficient for the use-cases in which these processors were deployed. In modern products however, we’re seeing designs in which larger memory addressing is becoming necessary. Modern SSDs right now for example routinely use up to 2GB of DRAM memory on their controllers, which comes near to the 32-bit 4GB memory addressing limit of the R8 CPUs.
The new Cortex-R82 enhances the core to enable up to a 2x performance improvement over the R8, uses a wider physical address space up to 1TB which is coherent with the rest of the system.
Arm currently doesn’t divulge much about the microarchitecture of the R82 and how it differs from the R8, but we imagine there to be some significant changes with the shift to the Armv8-R architecture.
An important addition here from the architecture and µarch side is the optional inclusion of NEON units for SIMD processing, including new dot-product instructions. This would enable for higher performance parallel processing compute capacity on the processor itself, allowing customers such as SSD-controller designers more flexibility as to their designs.
Another big change to the microarchitecture is the inclusion of an MMU, which allows the Cortex-82 to actually serve as a general-purpose CPU for a rich operating system such as Linux. This is actually quite a huge change in regards to the target market possibilities of the -R series going forward if the processor can run its own OS all by itself.
Arm’s product presentations focus on storage controllers, able to run both real-time workloads like they have been until now, but add in a rich OS for more complex algorithms and higher-level applications that aren’t as feasible on a bare-metal and real-time operating system.
A chip designer for example can tape-out a drive controller with multiple R82 cores (the design scales up to a 8-core cluster), and flexibly change the processing resources between the real-time application and the higher-level computation workload.
As the storage market evolves, one of the biggest requirements we’ve seen from our partners is flexibility. The new features of the Cortex-R82 processor give partners the possibility to design multi-core implementations of up to 8 cores, and adjust the types of workload running on the storage controller based on external demands in software. For example, parking lots will regularly use video surveillance to recognize license plate information which is later used for billing. During the day vehicle registration plate data is collected, meaning most cores are being used for intensive storage. At night, these cores will be used to process the data for billing and will adjust to carry out the data analysis and machine learning needed. As storage controllers are becoming more diverse to address different markets and features, Cortex-R82 delivers an architecture to provide this extreme flexibility – reducing costs and time to market.
Arm states that 85% of current storage solutions use Cortex-R processors, so the new R82 likely will represent a big jump in performance and open new possibilities for vendors to design new differentiating features in future designs.
Facebook
Twitter
RSS
26 Comments
View All Comments
Peter Greenhalgh - Thursday, September 3, 2020 - link
A real-time processor doesn't intrinsically process any differently from a normal applications processor. What differentiates it is that it bounds latencies and behaves deterministically. For example, rather than an interrupt latency on applications CPU taking anywhere from 50-1,000 cycles (or more) the interrupt latency can be bounded to under 40-cycles.Tightly Coupled Memories allow certain routines and data to be stored within the CPU so there's never any chance that a cache eviction has taken place which forces a fetch from DDR (or flash). In a phone or laptop, you don't have routines that absolutely must be accessed in 5-cycles and can't wait 250-cycles for DDR. If you're controlling an HDD you can't have the read head crashing off the spinning disk! Or, in automotive, the spark plug firing at the wrong.
Latency and determinism can be very important!
JACK4888 - Sunday, September 6, 2020 - link
I've had phones with "fast" processors and wait for a stored program to load from onboard storage. It is frustrating that so much of the code is bloatware. I have seen too many newbie "programmers" cobble together something that works but is slow but management needs code any code to push out the door. Cheap labor gets a poor quality product especially when there is little oversight. There has to be more oversight on the software quality control / peer review.AntonErtl - Friday, September 4, 2020 - link
In safety-critical hard-real-time systems, you want to prove that the system satisfies the time constraints under all circumstances. So you don't want to have good typical performance like mainstream CPUs; instead you want predictable worst-case performance. Features that improve typical performance, like caches, branch prediction, and out-of-order execution are not guaranteed to increase worst-case performance, in particular in statically provable ways. I heard about caches with true LRU replacement being pretty ok to analyze (but the usual Pseudo-LRU is much worse). Given that someone else posted that the R82 has a branch predictor, maybe someone found a way to analyze that, too, but again I expect that the branch predictor must have special properties to support the static analysis.michael2k - Friday, September 4, 2020 - link
Evidently the R7 had both dynamic and static branch prediction, so somehow they were able to satisfy the real time constraint in 2012.This says even the R8 had dynamic branch prediction:
https://community.arm.com/developer/ip-products/pr...
Not entirely sure how a real time processor needs to behave, but maybe the worst case scenario of a mispredict had it's penalty reduced in this design. The R8 was an 11 stage design and already had dynamic branch prediction, but that branch prediction isn't on by default so maybe there is a tradeoff in play to enable branch prediction:
However, the Cortex-R7 and Cortex-R8 do not enable branch prediction automatically at reset. This means software must enable branch prediction to get the maximum hardware performance.
domih - Tuesday, September 15, 2020 - link
Real-time is not about speed, it's about guarantying that a specific task will always be executed within a specific execution time, for example 10 milliseconds, not 15, not 5.Analogy: your heart is a biological real-time piece of hardware, it beats at regular intervals and each beat lasts a specific time. The speed may vary if you make some efforts, but it is still real-time. If one's heart shows arrhythmia a pace maker is often the solution. The OS on the pace maker is real-time too for obvious reasons, the task of sending electric impulses must occur in "real time". Same for monitoring cycling events, like a car engine for instance.
ZeDestructor - Thursday, September 3, 2020 - link
Is this core a derivative of an existing Cortex-A design (like an A72?) or is this something completely different?If it is a derivative, is there any public information on what the changes are? As a µArch enthusiast, I'd love to be given some more information on the changes done to the core and platform in general.
(yes, is is very much directed squarely at Peter Greenhalgh)
Andrei Frumusanu - Thursday, September 3, 2020 - link
I would assume they'd make µarch disclosures in the future. If it's a derivative, then it would be of the R8.Peter Greenhalgh - Thursday, September 3, 2020 - link
Not an R8 derivative. You'll have to wait to find out more though!Alistair Symonds - Friday, September 4, 2020 - link
For those who don't know and assuming this isn't just someone using his name, Peter Greenhalgh is VP of Tech at ARM, so he probably knows his stuff and can be believed here!michael2k - Friday, September 4, 2020 - link
Then the name R82 is kind of misleading :)