> 10 million write/erase cycles
this is not going to compete with DRAM, which needs to endure trillions of write/erase cycles in its lifetime.
Unless they grossly underestimated its durability, a name like UltraFlash would seem more appropriate?!
> The process was repeated five times, resulting in a little over 10^7 program/erase cycles applied to the device. As can be clearly seen in Figure 4d, there is no degradation of the ∆IS-D window throughout these tests, meaning that the endurance is at least 10^7.
https://onlinelibrary.wiley.com/doi/epdf/10.1002/aelm.202101...
Why stop at 10M? Is the erase operation really slow?
Ten trillion cycles would take over 150 years.
I'm guessing a silicon lab doesn't have "the rest of the computer" that would allow them to run this ram at full speed constantly. This UltraRAM isn't something they can just slot into their motherboard.
10 million is 14 hours. It takes longer than that to prepare your documentation. Something is rotten in Denmark. A skeptic could very, very reasonably assume that cherry-picking is going on here, and that 10m to degradation isn't far off from the truth.
> Assuming ideal capacitive scaling[33] down to state-of-the-art feature sizes, the switching performance would be faster than DRAM, although testing on smaller feature size devices is required to confirm this.
So, they have no idea of its performance. Yet.
Optane did inspire a lot of R&D into persistent data structures, databases and file systems that started to challenge the traditional model of local memory and persistent storage. IMHO, a few of those projects were a little bit overoptimistic, and used NVRAM as DRAM without many restrictions. For NVRAM to be viable, I think it still needs to have overprovisioning, wear levelling, memory-protection and transactions, provided by hardware and/or an OS but not necessarily with traditional interfaces. It is mostly a matter of mapping it CoW via a paging scheme instead of directly, and it will still be at near-DRAM speed.
The performance is so high that the assumptions that had led to the old file system interfaces don't apply any more. There is opportunity for something better.
begin()
try {
work on
several
in memory
data structures
commit()
}
catch {
rollback()
}
When writes are persistent and cause wear, the consequences of e.g. a common buffer overflow or use-after-free bug can be much higher than if they were not. Even an unoptimised loop that writes to NVRAM could be bad.
Maybe I'm confusing something, but to reach a trillion cycles in, say, a year, would take overwriting all your memory 30 times a millisecond. That doesn't sound right?
Or is that trillions of any writes and erases?
Still if you only changed the state of the memory once per frame, you would do it in RAM, not in cache. At 1000 FPS (we should consider the worst scenario even if rare) that's 3 hours of playing a game to reach 10 800 000 reads/writes.
Now question is what happens if that bit gets damaged, perhaps the memory just disables it as damaged, and uses another bit for this memory address from now on. Perhaps it makes the ultra ram slower over time as more bits (sectors) get damaged?
I agree that some regions risk being R/W more than others, so memory controllers should indeed perform some kind of wear levelling, but otherwise I find it hard to imagine trillions of overwrites across GBs (or TBs) of data. 1e6 cycles is definitely doable, and on the low side, even for flash devices. 1e9 is pretty good for general-purpose memories, and few applications require 1e12. Not even SRAM or DRAM have unlimited endurance, due to physical wear. It's hard to find a source on this, but I would probably hand wave it at around 1e15 cycles for DRAM? This would be 30 years of operation for one access every microsecond.
I think a trillion, or at very least 10s-100s billion is the correct amount of cycles for RAM.
Lots of non-pathological workloads might write to a memory location every millisecond, such as a game with a 4-pass renderer running at 240Hz.
Until recently a billion was a trillion, or vice versa, depending on whether you're from the UK or the US.
A GHz is a GHz no matter where you are. :-)
That's not true, a shared counter (i.e., an atomic integer) is cached – in fact, there's no guarantee that its value is ever written back to system RAM.
You're probably thinking of non-cacheable memory: the kernel can set the MMU attributes of a memory page such that the CPU will avoid the cache when it accesses addresses in that page. This is completely independent of atomic accesses on memory locations [1].
[1] At least typically – there may well be CPUs which disallow atomic accesses on non-cacheable memory.
You would probably go for some approach where most memory addresses are direct-mapped, and then the few that have been written most are redirected to new addresses.
The reading of the direct-mapped addresses would be super fast, since you can do the read in parallel with the lookup in the remapping table (just to check that this is a direct-mapped address). Reads of non-direct mapped addresses might take a couple of extra cycles, but that doesn't matter because they are very rare.
To do any of that, CPU memory controllers need to be able to handle per-request variable-latency RAM, which to my knowledge today they do not, although it would not be a big redesign to add.
Assuming a typical 5-year lifecycle, 10 million writes means 1 write every 15 seconds. That's more than enough for executable code, CDN content, or a database index. I can definitely see systems with 75% UltraRAM for read-heavy data and 25% traditional RAM for write-heavy pages acting basically as L4 cache.
The current set up is based on separating volatile and non volatile memory and adding caches to paper over the slowness. Caches are getting bigger and bigger because of the huge speed disparity. I think you underestimate how much of a game changer this could be.
This is persistent and fast.
If this takes off, and it does only last 10s of millions of cycles, just use cache for fast changing things and ultraram for everything else.
If it lasts trillions of cycles, it potentially would completely change pc architecture. It was the 80s when we had ram/rom that could keep up with the processors of the day. This potentially gets you an instant on computer, no need for caches, no need for memory for the graphics card, no separate hard drives. Just one big simple bucket of bytes for everything.
RAM is not easily removable in most of today's electronics. So replacing RAM once a year actually means replacing all your devices once a year.
no one complains about not being able to replace the processor in their phone because it 'never' breaks. batteries on the other hand do, and to varying degrees are replaceable.
https://www.youtube.com/watch?v=X7C_hdJsY4Y
I think for my kids I may have them skip traditional through wire soldering for SMD with hot air and toasters.
https://hackaday.io/project/27900-reflowduino-wireless-reflo...