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