This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why Cortex-R series is real time oriented ?

Hi Forum,

Why Cortex-R series is real time oriented than other ISA(ARM/others) ?

Is there a list of all the points and comparison with ARM Cortex-A ?

Why we can not make Cortex-A to suite for real time, which brings to think of Cortex-R ?

I am trying to understand from a software developer point of view.


Ravinder Are

  • My colleague Neil posted this article earlier in the year which may help as an introduction to the Cortex-R family:

    Five things you may not know about Cortex-R Series processors

    Before going into too many details, at a very high level an OS like Linux generally needs a memory management unit (MMU), so you would need to look at the Cortex-A series. However if you are looking at real-time operating systems or simply bare metal programming, then maybe Cortex-R is what you want.

    To answer this fully, we first need to consider what the requirements of a real-time system are.

    The first expectation is that the system is able to respond quickly to external events such as interrupts. The next is that the response time is deterministic. In most real-time systems, there is the concept of worst-case execution time. It is important to be able to guarantee system response within a bounded upper time limit, otherwise the system fails. This is often a stronger requirement than having an overall high average level of system performance.

    At a high level, the Cortex-R and Cortex-A families have a similar architecture. They have the same exception model (for example privilege levels for operation) and the same register banks. The main differences are in the memory system architecture, and it is here the Cortex–R class family has a number of features that help address the requirements of a real-time system.

    Cortex-R devices have a memory protection unit (MPU) and implement the Protected Memory System Architecture (PMSA), rather than a memory management unit (MMU) found in Cortex-A cores, which implement the Virtual Memory System Architecture or VMSA. The MPU allows sections of memory (which could be code, data, or peripherals) to be protected or isolated from each other, but the address space is always physically mapped – there is never any address translation within the processor.

    In a system with an MMU there are risks that might affect worst-case execution time. The first is that a translation table walk is taking place when an interrupt occurs. These operations need to complete before the interrupt can be taken, and yet the completion time of these is not always easy to calculate (in systems with multiple levels of caching it can be very complex) but could be 1000’s of clock cycles. In the average performance case this may be an infrequent occurrence, but as mentioned, for many real-time systems it is the worst-case timing that sets the overall system requirements, and the worst case timing for a page table walk can be significant compared to typical interrupt latency. Furthermore, the next complication is that the interrupt routine code you may need is not present in the cache – resulting in a minimum of an access out to the level 2 memory system, but potentially also resulting in further translation table walks.

    The Cortex-R family doesn’t have virtual memory, so there is never any translation table walking to worry about. However there is still the possibility that critical code may not be cached when needed. The Cortex-R family addresses this with Tightly Coupled Memory (TCM). These are usually small areas of memory that are closely coupled to the CPU core so they can be accessed quickly. These are not caches (although they often have cache-like response time), so critical sections of code and data can be stored in them to guarantee response time. Items in TCM are never copied out to slower parts of the memory system – they have their own address space within the system. Larger TCMs can be used, sometimes with a wait-state on each access, but again, the system performance is within guaranteed bounds, and is consistent across all accesses to the TCM.

    Some of the more advanced Cortex-R processors have additional features to help meeting real-time requirements. In the Cortex-R5 and R7 a Low Latency Peripheral Port was introduced. This is to enable CPUs to access peripherals without potentially having to wait for other accesses on the main AXI bus to complete.

    Finally, many real-time systems have requirements for error correction and detection. The Cortex-R family introduce features such as ECC on caches, TCMs and on the R5 and R7 the AXI system busses to allow hardware correction and detection of errors. Systems that have functional safety requirements (such as those meeting IEC61508 or ISO26262 standards) often have hard real-time requirements. In addition to the ECC support, the Cortex-R family also has features such as Dual-Core Lock Step which helps system designers create a system meeting those safety requirements.

    ARM recently released the Cortex-R series programmers guide: ARM Information Center 

    This goes into much more detail about the areas mentioned above so you may find it worth a read.

    I hope that helps, but do let us know if you have any more specific questions.

  • Hi are and probablly all,

    simply, I think the important points are TCM (i.e. no cache usage) and MPU (i.e. no MMU). Caches and an MMU behaviors don't have deterministic processing time, because of their mishits.

    By the way, I think if the lockdown features would be implemented for caches (especially L1 caches) and the MMU, the caches and the MMU could be usable even under the real time environment. However, regarding recent trend of the ARM architecture implementation, the lowdown feature sometimes (or always) was ignored. I would like to know the reason.

    Best regards,
    Yasuhiko Koumoto.

  • Further to the earlier replies, there are one or two other features which make ARMv7-R processors more suitable for real-time.

    They have support for an NMI interrupt (by making FIQ non-maskable) which improves applicability for safety-critical real-time systems.

    They support something called "Low Latency Interrupt Mode" which allows the maximum interrupt latency to be reduced by making certain lengthy instructions interruptible.

    They support integer division in hardware, which improves throughput for critical calculations.

    Hope this helps.


  • ARM have designed a new top level R series design ARMv8-R

    ARMv8-R Architecture - ARM

    this allows an ordinary operating system like Linux that would run on an A series processor in one of its virtual machines. But at the same time it can run some real time processes where you want guaranteed response time for an interrupt and it has all those facilities for dealing with possible errors like the other R series processors. If you ran Linux trying to operate the brakes you wouldn't be able to guarantee when it could deal with interrupts and the car might bash into something. To guarantee times one really wants to avoid as much unpredictable time like caches and virtual address table walking as possible otherwise you have to assume the worst case may happen with them, and you have to be very careful about which interrupts can interrupt or take precedence over others and when