Arm Announces Cortex-R82: First 64-Bit Real Time Processor | Hacker News Reader

Arm Announces Cortex-R82: First 64-Bit Real Time Processor

anandtech.com

303 pointsrbanffy105 comments

The best part is actually Peter Greenhalgh, VP of Tech at ARM wrote in the comment section.

>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!

>Not a R8 derivative.

I cant wait to see a SSD Controller with this tech.

>I cant wait to see a SSD Controller with this tech

I doubt this will improve SSD controllers, whilst this may have more granular control over the CPU cache. For example - if there was an SSD controller that this was drop-in compatible, I doubt there would be any measurable gains due to the NAND latency and that if your a little late, the NAND isn't going anywhere.

Spinning rust, now if you miss the rotation, you have to wait a full rotation. However, given rotation speeds, the processing has been fine as and the days of interleaving sectors to time the controller performance died out decades ago, so I'm not sure that example would see gains.

Remember that in these cases the code is kinda fixed and the only dynamic is streaming the data in or out and processing upon that data (encoding/decoding) - all fixed. So if the core/cache is fixed upon one task, the whole latency aspect is controlled and known. However, if you want a CPU to do many things, then this level of cache control and interrupt handling would be more important, so then you need an RTOS.

Though I'm sure many a dB would love the ability to run code directly upon the drive controller - then with RTX30 opening up direct drive interfacing over the bus and circumnavigating the CPU[EDIT]- then again, this may well have some advantages.

[EDIT ADD] Easier access to large ram caches seems to be the real gain, so for spinning rust HD's, that becomes a mixed blessing as would ideally want some capacitors to make sure that memory buffer is written in case of a power failure - so more memory buffer, large capacitors to make sure enough power to flush that buffer to the spinning rust. So be interesting how that pans out.

The FTL layer in modern SSDs is far more complex than you're describing above. It's not about NAND latency, it's about having good enough scheduling and enough raw throughput on checksumming and such to match the ever increasing stacks of NAND and consequent bandwidths.

> I cant wait to see a SSD Controller with this tech.

Not sure I understand your angle, because as I understand things the lags and stalls experienced on (usually older) SSDs stem from the controller either having to re-read a page many times over to reconstruct it or for the controller to have to perform housekeeping RFN because some buffer is full. To that end, because of the virtually addressed nature of SSDs with the "page tables" (if you will) being stored on the SSD as well you run into similar issues as kernels do under memory pressure, causing thrashing.

FWIW, the 64-bit part is new, but TCM and fast/bounded interrupt response are features available in past and present Cortex-R and Cortex-M devices. If you want to play with this stuff now and don't need a 64-bit device, there are plenty of options.

What benefit do you believe this is going to bring SSDs? They are full of DRAM buffers and utilize multiple simultaneous NAND channels to mask latency inherent to the tech. It seems a realtime processor would bring little to the table.

Edit: Well looking into it a bit, a lot of SSDs already use realtime ARM processors in their controllers. The main benefit here seems to be being able to address larger buffer sizes going forward and access to more cores.

Not having to work around the limitations of 32-bit addressing is a convenience, but the industry has produced 4+ TB SSDs with 4+ GB of DRAM for quite a while now without this core.

The real demand for a core like this in SSD controllers comes from doing more computationally expensive work on the SSD controller than just providing a block storage device abstraction. Stuff like embedding a full key-value database on the SSD or providing more general-purpose compute capability is a hot topic for enterprise storage. There's already at least one company shipping an SSD controller for computational storage with a mix of realtime cores and Cortex-A53 cores. The Cortex-R82 means such a chip could be more homogeneous with just one type of ARM core.

From another article:

> With approximately 85% market share of storage processors, this is an important market for Arm.

https://www.forbes.com/sites/tiriasresearch/2020/09/03/arm-c...

Not sure what that means in practice though, this is out of my scope.

> data to be stored within the CPU

I don’t know anything about CPU design. Am I wrong to read this line and be worried about memory access vulnerabilities like have been found with Intel CPUs?

Tightly coupled memory is basically a cache, except it's explicitly mapped at an address. In MCUs it's faster and also more "secure" in a sense, because, just like a cache, you can't DMA into TCM, so peripherals can't write garbage or shellcode into TCM. The upside of TCM over a cache is that it doesn't need the quick logic to for cache lookups and the storage for tags (so smaller, lower power than a cache), while the downside - it being explicit - is less of a problem and sometimes an advantage in embedded systems.

I understand a lot better now, thanks!

Many MCUs / SoCs support DMA into tightly coupled memories. Very useful for "ping-pong buffering" to hide memory copying overhead - copying one buffer into a TCM bank while the processor works on a different TCM bank.

Local memory can also be handy in general-purpose computing - there's always some data that belongs to a given core that doesn't need to be consistent across shared memory.

> 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

Well, there are very tight timing in the cellular communication stack of a phone, probably more so than in automotive (though consequences of messing up may be less severe). These are usually offloaded to ASICs, though, but still, plenty of tight real-time deadlines in a phone.

TCM was available for some older generation of ARM processors. Is there some new about this implementation?

The new parts are 64-bit instruction set and MMU.

So this is basically a CPU with an upper bound on the horrible cases. That's useful for real time. A standard test for real time is to run a hard real time OS like QNX, and have a simple program which receives an interrupt from an input pin and restarts a high priority task that's waiting for the interrupt. The high priority task turns on an output pin. You hook the input and output pins to an oscilloscope. You want to see all the output spikes about the same distance from the input spikes. You don't want to see output outliers way out there, late. If you see that, it's not a hard real time system. You can do this with a standalone program to test the CPU by itself, but you really need to test it when the CPU is also doing other things.

Sources of CPU-level trouble include 1) rarely used CPU instructions that run slow microcode, 2) cases where the pipeline needs a total flush and that's slow, 3) the board manufacturer doing something in system management mode and not telling you. Drivers locking out interrupts too long is the usual Linux problem. It's assumed that all real time code is locked in memory; you do not page real time processes.

Is there any upper bound on latency for something to qualify as a realtime system? For example, a system that is guaranteed to compute its output at the end of each week?

To put a slightly different spin on qwertox's reply: What matters is that the OS can guarantee how long it will take for, say, a high-priority task to become active after it is activated. It's not a matter of the absolute numbers; it's the ability to make a real guarantee. Of course, the bigger the number, the harder it is to make a guarantee at all, because there are more things going on, and are you sure you got all of them? But with a real time OS, there are far fewer things that happen in such a case, and so it's easier to calculate and to prove that yes, it really will respond within X cycles.

There's a lot of subjectivity in these definitions. But an overnight batch job run once a week would usually not be considered a realtime task. The duration of the job and the time resolution of its deadline is pretty large compared to the CPU scheduler timeslices used by general-purpose operating systems, and you probably don't need any special hardware support. You just need to provision enough CPU time overall, and not allow the job to be starved by higher-priority tasks consuming all the available CPU time.

A task would usually be considered realtime to some degree if it cannot automatically get its work done on time even when competing with a background-priority long-running job—for example, if your deadlines are operating on similar or smaller timescales to the operating system's CPU scheduler. Then you need to start taking extra measures to ensure adequate responsiveness, not just adequate throughput.

But there's also the aspect of consequences of missing a deadline. Most realtime tasks are concerned with millisecond or shorter timescales, but a job that must be performed once every 108 minutes to prevent the end of the world would also be reasonably considered a realtime task.

Yeah, it would be nice to have a real-life example with a relatively lengthy latency. Perhaps with delivering an organ for a transplant or something.

At least wrt soft realtime scheduling for audio, I think users/programmers tend to get severely tripped up because the latencies are simply too small for them to make a clear mental model of the underlying system. That, along with their ineluctable desire for their code to "go faster" drives them to request features or design algorithms which would have to travel "back to the future" in order to work at all.

So it would be nice to decouple "ultra-low latency" from "realtime" to make it clear that, say, you can't put the heart on ice after the helicopter already lifted off to fly it to the hospital.

If you're actually paying attention to guaranteed worst-case runtimes to make sure that something completes within a week, then it would be fair to call that a real-time system and real-time techniques would be relevant. If you're running it on a backend with no firm worst-case guarantees and trusting that it won't take too much longer than the average time then that's not a real-time system.

If you're expecting to always get the data in 5 cycles but you sporadically get in 250 cycles, you're no longer on a realtime system. The latency per se doesn't matter, as long as it is what you expect it to be.

Its application-specific:

i.e. A spacecraft that requires a thruster to be fired with accuracy of a few hundred milliseconds in two years time has mission/safety critical timing requirements. Therefore this is hard-real-time

Alternatively, a payroll that has to run at the end of every month will not cause people to miss payments if that deadline is missed by any relatively large amount of time (minutes/hours). The timing requirements are not mission critical at this point. They could be considered soft-realtime tho as there is still an upper bound to desired behaviour.

Maybe you can clear this up for me.

To me, realtime means "responds faster than the fastest it needs to in order to control a feedback loop" which is super subjective since different system dynamics are so different.

When I tried to use RTOS it appeared to be that better than 1ms resolution was not remotely possible. Just hardcoding the interrupts resulted in 1us resolution easily.

I grant that the RTOS provides a scheduler, but when this chip says that it is intended for "realtime" does it mean that it's microsecond fast even when running RTOS, that it's capable of running fast with handwritten interrupts and code (which to me seems to be most things), or just that it has a spec for an upper bound on op timing?

I guess the last is important for correctness proofs but the prior two are how I interpret it as a confused person reading marketing materials put out by conflicting sources.

Actually realtime doesn't mean "responds faster than the fastest it needs to" but rather it means always responds faster than some predetermined threshold. A lot of the easier ways to make things fast (like caches, or even branch prediction) are inherently probabilistic; if the thing is in the cache you get wonderfully fast performance; if not performance falls off a cliff. A realtime system avoids that, making the average case much slower but the slowest case much faster. It basically flattens the latency distribution.

Does this mean realtime doesn't use caches and branch prediction a all? Or worst case of miss for cache or prediction miss is lower than realtime threshold?

A lot of hardware designed to support realtime applications will let you opt in or out of some of those features. So you have some ranges of memory that go through the usual cache hierarchy to off-chip DRAM, but you also have some memory that is directly mapped to on-chip SRAM that isn't a cache and therefore cannot suffer the latency penalty of a cache miss.

Stuff like branch prediction probably isn't too useful to implement as a switchable feature. Instead, the core is designed so that mispredict latency is still reasonably short (short pipeline, in-order execution or OoO with a short reorder window). This means you won't get as much benefit from speculative work as you would on a desktop-class core, but you're probably not going to be as vulnerable to Spectre-style attacks, either.

Its perfectly possible to have realtime requirements and still have variable latency as long as all the variability is bounded. Think video playback or gaming, both of which run on traditional OS's because they tend to be fast enough to meet the frame deadlines. Of course as we all know, the requirements aren't "hard" so dropping a frame/etc is a non critical failure.

So, there is a spectrum of realtime and how "hard" it needs to be. There are a lot of cases where simply having a real time OS on a traditional processor is fine as long as everything can be sufficiently bounded.

In one application I worked on, the caches were turned off completely. Slower, but more predictable latencies, and most importantly, without the huge latency spikes we would occasionally get with caches enabled. (Because of large cache misses.)

> When I tried to use RTOS it appeared to be that better than 1ms resolution was not remotely possible.

I've only worked with one RTOS, and a lightweight one at that.

The scheduler would run every time an interrupt handler finished running.

One such interrupt was the 'systick' - you can choose if you want it to run every 1ms, or 100us, or a different rate (depending on how fast your CPU is)

The systick was how you timed anything you didn't want to use a dedicated hardware timer for. If you want to wait 10ms and your systick happened every 1ms, you waited until the 10th systick.

If you want to time something with finer resolution than 1ms, you either made your systick faster, or used a hardware timer with the interrupt triggering the scheduler.

> Just hardcoding the interrupts resulted in 1us resolution easily.

If your CPU runs at 180MHz, 1us is enough time for 180 clock cycles. Plenty of time to run one reasonably carefully coded interrupt handler, not much time to run 10 interrupt handlers.

As you can imagine, running your systick at 1us with that clock rate would be challenging!

You can also have a 'tick less' scheduler for the systick style timer that won't have a regular period, but instead will dynamically reset the timer in each expiry ISR for the next scheduled event.

Realtime is a fluid (AFAIK) definition. In general, realtime concerns reaction time to inputs - how much (sic) of inputs are processed "in time". On one hand, you may want the system to react "quickly" to 99% of inputs on a pin. On the other hand, you may not care (within reason) when the system responds to UDP packet. To recap, realtimeness concerns amount of events on the same input processed "in time" and number of inputs subject to timeliness. Hence general confusion and multiple definitions.

I would say there are two (2) sets of realtime definitions.

1) concerning amount of events

Hard realtime system always produces output to an input in predefined time (subject to clocking). This time can vary between different inputs, but is fixed for a given input.

Soft realtime systems are bound - output time is bounded to some number.

2) concerning number of inputs

Hard realtime system has bound reaction time to every possible input

Soft realtime system has bound reaction time to "critical" inputs.

---

Definitions used in practice mix the two in some ways. The most prevalent definition I happen to come across in the general internet is something like "realtime system has bounded, low-variation reaction time to critical inputs".

I don't get the impression that in this case "realtime" means anything surprising – that is, it means "responds within a well-known and deterministic time." As you point out, that time is usually slower than a non-realtime system would offer.

Specifically with the R-family ARM chips, there is support for things like tightly-coupled memory (https://developer.arm.com/documentation/ddi0338/g/level-one-...) to provide latency guarantees for real-time code, deterministic interrupts, that kind of thing.

I see, thanks. I can see an advantage to being able to say that your average performance isn't as good but your variation is small, you can prove you'll hit your metric. I guess I usually over-engineer by 10x but maybe a better coder would do a better job of running up against the limits.

As others said, the difference is very significant.

Real-time systems show up especially in industrial control and safety systems. For example, take a logging harvester, which cuts down trees and strips their branches and bark. It has a control panel for moving incredibly violent, dangerous machinery. It is truly critical that you can guarantee that, for example, sensors which detect a problem can abort something within a very tight latency budget.

> average performance isn't as good but your variation is small, you can prove you'll hit your metric

I think you are missing something here.

Real Time systems aren't designed for high performance at all and instead they are designed for predictability.

You aren't aiming to "hit your metric", you are aiming to never, even go below it.

This is useful for something like old-style spinning hard drives where you had to calculate where to move the head of the disk within the time of the rotation. You have a instructions/second budget, and you know it will execute that.

On non-realtime hardware (and software) you know how many instructions/second it can do, but things like speculative execution of caching strategies or non-RTOS mean those instructions are not guaranteed at all.

I'm confused, aren't "don't fall below your spec" and "hit your metric" synonyms? In what field are they not?

"Hit your metric" commonly refers to average (or some percentage of average) performance being within bounds.

It's pretty rare in software for it to define minimum performance. There's good reasons for this - software is interacting with intrinsicly messy things (like humans) and so performance outliers are a big factor.

It's pretty common in software for the worse case to be 10x the "hit your metric" case, and this isn't viewed as bad: the worst case happens rarely enough for the trade off to be worth it.

Ah, thanks for the clarification.

I am coming from the hardware world, through raw assembly, to C so my path is very much the assumption that if the microcontroller is going to control a feedback loop that stabilizes at 10MHz it will be guaranteed to do so.

But I suppose that I actually do that by overspecifying things nowadays since it's much too unpredictable as you say to predict how long things will take.

To me if you say you sample at 100kHz you sample at a minimum of 100kHz. Very very good to know that if I work with a firmware engineer that they won't hear the same thing as I mean if I say that it needs to hit a 100kHz sampling rate.

It would be very disappointing if they wrote a loop designed to average a 100kHz sampling rate with random jitter... (kidding mostly, I'd assume they would at least not do that).

Firmware engineers would probably think in the same terms as you about sampling frequency.

"realtime" means "latency is bounded to some documented value". "Hard realtime" means it never exceeds that value, and has the same latency every time. "Soft realtime" means it never exceeds that value but the actual latency varies.

That value doesn't have to be anything in particular. Could be 1ms. Could be 100ms. Could be a year. It just has to exist and be documented, and never, ever be exceeded by whatever operations are covered by its guarantee.

Your description of hard vs soft realtime doesn't match any that I've previously encountered.

Generally, hard realtime means missing a deadline in unacceptable, but does not necessarily imply that latency is exactly fixed—just bounded. Soft realtime means that the consequences of missing a deadline are less severe, so the system may allow for some missed deadlines: eg. dropped packets for a video conference or delayed frames for a video game are noticeable especially if they become common, but they don't crash the whole system and the system remains useful even after missing a deadline.

>and has the same latency every time.

There's no such requirement.

All hard realtime needs is the guarantee that the value will never be exceeded.

Right. Should have written "same maximum every time". Went stupid for a minute.

I'm pretty excited by this announcement. Not for storage but for software defined radios. If Xilinx upgrades their RFSOC (which is an Zynq Ultrascale variant with built in ADCs and DACs) to this core from the current A53 core it will allow much more sophisticated base band processing in software that is currently done with FPGA gates in the fabric. And while reconfigurable FPGAs are nice, software can change modes much more quickly than reconfiguring an FPGA can.

Question: are GPUs a consideration in the SDR world?

I'm no expert on SDR, but it seems to me that SDRs are the high bandwidth and parallel workloads where GPUs excel in. (GPUs can perform fourier transforms very efficiently)

The only possible qualm would be the latency of a GPU. But I don't imagine that SDR workloads are very latency sensitive? Or am I mistaken there?

GPU kernels are just software, but the parallel nature of GPUs means that it's better if most of the GPU is sharing the same code (very small L1 code cache per thread). So it's far more flexible than a FPGA but somewhat less flexible than a CPU (where different cores and threads can be executing very different code with large and unique L1 caches)

Yes! There is a very active community of using Cuda to do signal processing[1].

Latency is an interesting thing, its always part of the SDR pipeline since you have filter delays and processing delays. Most digital streams are uni-directional so you get the bits out, just shifted by 'x' nS. Since the 'x' is deterministic you can plan for it.

[1] https://github.com/rapidsai/cusignal

That's pretty cool. I don't know anyone who does realtime signal processing work in Python, though, least of all myself. Are there C bindings for all of that stuff?

Nearly all of the "heavy lifting" as it were are C or C++ libraries. Python is just the 'plumbing' level. It is not dissimilar to using MATLAB where the drivers are all optimized code but the connection between them is MATLAB.

This design pattern is a common of nearly all SDR frameworks (Gnuradio, Redhawk, Pothos, Etc.) The "interconnect" between processing elements is typically shared memory, and that is why it lends itself to GPU work as well.

That said, since my head is most comfortable thinking in C, I tend to write stuff in C rather than Python :-).

I'm not sure if this is precisely what you are looking for, but it's been on my radar for a while for a potential upcoming project. It has limitations (64-bit Windows only, for one) which is why I haven't acted on it yet. But it is part of my pre-project research just the same.

https://github.com/taroz/GNSS-SDRLIB

NVIDIA and Ericsson are already working on leveraging GPUs for 5G:

https://www.ericsson.com/en/blog/2020/4/hardware-acceleratio...

I don't know if this involves baseband processing or just protocols and tighter coupling of applications to the network to reduce overall latency.

This effort is certainly driving a reduction in jitter which is currently an issue with many realtime GPU applications.

I've seen it done on the PC side, but (at least on my budget) implementing a GPU, and an FPGA, and the actual SDR I haven't seen. It's definitely a good idea but whereas I could definitely do a decent spec arm board with enough time and prototypes to get it right, I don't even know where to start when it comes to even getting a GPU to boot.

I would be keen to see if GNSS-SDR can run on a multicore version of this CPU. We are developing fully software GPS / Galileo receivers using the Analog devices AD9364, and are able to run it on a quad core Kaby lake laptop.

Why do you need more than 2GB in real-time? In real-time the less the better. 64bit puts a huge burden on everything, the MMU also. Now people will start using operating systems which are not built for RT, like Linux, and wonder why the cycles start failing and the system constantly reboots. Driver availiability of course which drives down HW costs, but best use an extremely limited IO and only one fast IO to meet your cycle goals.

I see that it's better than a custom FPGA, but a normal 32bit rt cpu with half the memory pressure and pointer size looks much better to me.

I take it you haven't processed SAR data :-). In the Zynq Ultrascale series you can have DDR hanging off the fabric that is accessible through the AMBA bus to the processor. Having multiple cores doing overlapping convolutions on spectral data in RAM can run fast enough to give real time tracking latencies.

They probably won't though, because the R core I don't believe has an MMU for Linux

From the article: "Another big change to the microarchitecture is the inclusion of an MMU"

This is pretty massive! If fpga vendors provide this, what a great addition.

Hence my enthusiasm :-)

What level of interposition can one do with these hard cpu cores? Are the cache eviction policies pluggable? Is "user code" in the path between the cpu and main memory?

On the Ultrascale Zynq's you can build RAM that is attached to the fabric and available to the processor across the AMBA bus. It isn't something I personally have played with a whole bunch so I can't give you a better answer then to look at the Zynq data sheets.

I do know you can make user hardware "appear" as memory to the main CPU.

Neat. I am stoked to play with the new PolarFire RISC-V Icicle board.

https://www.microsemi.com/existing-parts/parts/152514

https://www.crowdsupply.com/microchip/polarfire-soc-icicle-k...

> “real-time” processors which are used in high-performance real-time applications.

C’mon anandtech, you can do better than this: “real time” means deterministic, not necessarily faster, and in fact often means slower.

As another poster pointed out, ARM’s VP of Tech posted a comment and posted what real-time means. I don’t know why people jump from that to some idea it would be faster.

I think the point you're missing is that "low performance" realtime applications exist and can often get by with more commodity hardware and careful software, eg. running a RTOS on x86 hardware. But that's usually not a viable option when your latency requirements are measured in clock cycles or nanoseconds rather than microseconds. For that, you need more specialized hardware that can do realtime and high performance.

"high-performance" could just as easily be interpreted as faster response time as compared to faster clock speed. So in that way they are "faster".

But real-time systems don’t guarantee faster. I was a real-time engineer for years.

Faster latency, not faster throughput.

Not necessarily even lower latency, just predictable.

In general usage, to perform means to do a job well, to fulfill the requirements well, right? But in computing in colloquial usage it's near universally used as a synonym for high execution speed.

"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."

That's interesting, but they seem to be removing most of the differences between the A and R series.

Not really. The performance-oriented A series can include -- and will continue to include -- features which improve performance at the expensive of inconsistency, such as branch prediction and speculative execution. The R series values consistent behavior over performance, so it won't have those features.

R82 is in-order, but does provide branch prediction. [1]

[1] https://developer.arm.com/ip-products/processors/cortex-r/co...

Another usage for the MMU would be in a virtualization context. The Hypervisor can configure static address translation tables for each RTOS VM.

The MPU (Memory Protection Unit) in the ARM architecture is like an MVP MMU in that it doesn't have the flexibility of an MMU as the MPU has protection domains (ranges of memory and access semantics bits) and doesn't do address translation like an MMU. It is analogous to mprotect()

I haven't used it, but depending on latency and complexity of updating the MPU config, one could dynamically program it to have an arbitrary levels of protection, think hardware range checks at language level array access.

[1] https://static.docs.arm.com/100699/0100/armv8m_architecture_...

https://man7.org/linux/man-pages/man2/mprotect.2.html

The title is a bit ambiguous - this is ARM's first 64-bit real time processor, but it's not the first one out there. All of SiFive's S and U series cores are 64-bit with hard real-time determinism. [0]

[0] https://scs.sifive.com/core-designer/

Realtime capable hardware and software is all super intersting. It makes up for a very different challenge when building that something that has to fulfill a certain task in a certain amount of time instead of just providing a best effort solution. Therefore I'm always curious to learn about products and solutions in that field.

However for this presentation I'm a bit puzzled by some of the marketing slides:

- Optional NEON accelerates ML.

- Advanced machine learning support

Is that really a use-case for those processors? Can ML be hard-realtime anyway? I feel like a promotion that one could use those SIMD instructions for e.g. erasure-coding on storage use-cases or e.g. for signal processing on Telco/Audio/Video use-cases would be much closer to typical applications for such a CPU.

Is it just me or sounds the "ML" on these slides more like "we need to join the hype" than an actual use-case?

- Optional MMU enables Linux and cloud-native software development

I agree - MMU is great, Linux support too. But what is cloud-native again? And is something that runs on a SSD controller in a datacenter now cloud native?

> Can ML be hard-realtime anyway?

Sure, why not? The number of instructions needed to run inference on a given neural network is known so I don't see any real issues here.

(Training is of course a different matter)

> Is it just me or sounds the "ML" on these slides more like "we need to join the hype" than an actual use-case?

You could build query-by-example indexes (for text, sound, images or videos) in the storage hardware with this kind of capability. That'd be pretty interesting.

Imagine something like Isilon, but instead of allowing Hadoop analytics on the storage hardware it could do approximate nearest neighbour across images.

(This is actually a pretty good idea...)

> You could build query-by-example indexes (for text, sound, images or videos) in the storage hardware with this kind of capability. That'd be pretty interesting.

I've seen demos of this kind of thing from companies like NGD Systems, who use Cortex A53s in addition to realtime cores in their SSD controller. Part of the selling point for offloading this from the CPU is that code running on the SSD controller has much faster access to the dataset and can query it more efficiently, unconstrained by the drive's host interface.

There are also more mundane use cases for ML inside a SSD as heuristics to predict data access patterns or media wearout trends, which can influence how the SSD chooses to store data and tackle error correction.

The wheel of reincarnation turns again.

Back in mainframe days, "channel controllers", the subsystems that controlled storage devices, were very programmable. At some points in time, it made sense to off-load as much as possible from the CPU onto the channel controller. At other points in time, the reverse was true.

For a couple of decades, we've had dumb storage devices. Now with some of the NVMe stuff, we're moving back towards smart "storage".

Linux in an SSD is the same idea.

Disk controllers have been "smart" for the last 15 years. There's just a desire to run Linux instead of a barebones RTOS.

Lot longer than 15 years. There were ISA SCSI controllers that had micro-controllers which could be programmed at some level. The symbios SCRIPTS come to mind which were common on the 53Cxx controllers.

https://www.manualslib.com/manual/96635/Lsi-Symbios-Sym8953u...

This has continued on raid/fibre/nvmeof/etc boards.

What would be the advantage of running an RTOS on Cortex-R82 vs any other ARM processor? Doesn't an RTOS give you the hard realtime capability through software?

I feel I must be missing something critical in my understanding. I thought RTOS in software was sufficient to get realtime processing.

Your software can only guarantee what the hardware provides/guarantees. If your cpu can take a variable amount of cycles to start processing an interrupt, the RTOS can only guarantee the upper bound. A real time cpu is all about being faster and more importantly more deterministic, therefore enabling the RTOS to guarantee faster reaction times.

If an interrupt can usually be processed in 50 cycles but very rarely will take 500, the RTOS can’t schedule for the 50 cycles. If the real time cpu guarantees 200 cycles, the RTOS can actually schedule with that. Depending on the application, that can make a huge difference.

See this comment: https://news.ycombinator.com/item?id=24401929

For those like me who didn't know what a "Real Time Processor" was: https://en.m.wikipedia.org/wiki/Real-time_computing

(somebody correct me if this is wrong)

I'm also interested --

What's the hardware difference required to support real time? Is it some dedicated parts of compute to support the queueing / prioritization of jobs? And some additional ability to have the "master" must-always-work part be able to interrupt or reset "optional" processes?

Deterministic latency. That usually means no cache, speculative execution, or anything else that can't guarantee it will complete in a reasonable time.

Specifically, in many architectures interrupt handling code must be able to yield _very_ quickly in order to continue receiving interrupts (or use reentrant interrupts which are a whole other mess) and even a cache look up, which might fail and have to wait for DDR ram for hundreds or thousands of cycles, makes the system unable to guarantee that it will do what it needs to do in time, like respond to some safety shutoff switch.

I think one of the things ARM did here is make a way for interrupt handling code to stay in cache permanently along with some other determinism guarantees.

Thanks! I guess in the designing of the accompanying software then, the people writing it probably spend equal (or more) time in writing what happens if the expected/desired behavior fails, than if it succeeds?

It sounds analogous to the question of deterministic memory usage (vs GC), but at a hardware level and for runtime instead of memory

Realtime is both software and hardware.

A realtime OS won't do much preemption, probably would rather stick to cooperative scheduling.

On the hardware side, explicit cache controls are big in realtime chips. Your programmers know exactly which data is in cache and what isn't, and therefore can accurately plan how long tasks take.

The MMU traditionally wasn't realtime. I wonder how they managed to get realtime controls with virtual memory. (They must have some kind of guarantee on TLB lookups or something)

> realtime OS won't do much preemption, probably would rather stick to cooperative scheduling.

I've seen realtime OSes that were very preemptive, at least between priorities. Tasks/processes had priorities, and a higher-priority task that became active would preempt anything lower-priority that was running. vxWorks ran this way, IIRC, and it wasn't alone.

There's also Real Time Java

https://www.oracle.com/technical-resources/articles/javase/J...

This could be an amazing chip, I imagine its a replacement for the R5?

The article talks about it like it's a replacement for the R8.

It's also called the R82 so I think that makes sense.

Does real time mean that there is a minimum time an operation will take as well as a maximum?

Asking because a minimum time could prevent some kinds of timing attacks.

Has anyone compared this to real-time capabilities of Intel hardware?

Is this just a native way to prevent interrupts on specific cores?

I believe it’s more determinism than just the interrupt timing.

32 bit versions are used in stuff like your WiFi chip.

I wonder how you can get a dev kit for this.

If I remember correctly, having a capable RTOS is much more important, and they can be used in regular processors too [0].

I wonder what's so special about this processor that makes it better than dozens of other hardware platforms (both microprocessors and microcontrollers) on which embedded RTOSes are running and doing just fine.

Also if you have a 64-bit processor, but no 64-bit RTOS, you don't have much.

[0] https://en.wikipedia.org/wiki/Comparison_of_real-time_operat...

You dont really need more than 2GB RAM in RT, it's a huge burden. Not even more than a few megabyte. Also 64bit pointers are twice as slow as 32bit pointers. Just think of randomly jumping around in your terabyte ram. Filling the cache lines cost 50 cycles alone, and your budget is usually around 40-100. A 64bit rtos might be usable for image detection (self driving cars), but not much else. The cpu cannot be general purpose, gpu's can do that much better. I don't really see the market for such a thing.

It's not uncommon to have RT workloads where the "hard" RT part can fit in a small amount of tightly coupled memory, but the same processor is also used for "soft" RT workloads that need a much larger amount of memory. 64-bit addressing makes developing this kind of system a lot easier.

Reply on news.ycombinator.com