Resistance is... new style: Samsung says it's now shipping resistive eMRAM for IoT chips Samsung this week claimed it is mass-producing and commercially shipping embedded magnetic RAM (eMRAM) to replace EEPROM, SRAM, and NAND memories in embedded electronics. NAND flash memory is increasingly unable to meet today's embedded controllers' speed and density needs. There is no Optane-class technology for this …
Unless I missed something, we’re still unable to take pieces out of files or add something at the beginning/in the middle. This is, because our systems were based on tape recorders. Adding something in the middle or at the beginning was simply impossible.
Today we have random access SSDs with block-based file-systems and we still treat them like tape recorders. As much as I hate being the Cassandra, just imagine how long it’s going to take before your system will truly utilize something like eMRAM. ;-)
What are you talking about?
You seem to be confusing so many things. The data storage medium has no more relevance than the file format itself. Modifying something in the middle of the file is reliant on so many things including the way the file format lets you locate what you are looking for. Not just how you read the file from storage and if you load the entire file into RAM that can be ignored anyway.
A text file for example is the simplest file format I can pull from the air. Yet to locate the section you wish to edit, you will need to at least run a grep/regex over the text, or count line endings. To do this you must read from a start point. None of this has anything to do with the storage medium. Its closer to how algorithms generally work. The basic concept of the array for example is a linked list with the elements of the array linking to the previous or next element. Nothing to do with storage, everything to do with counting.
To do what I think you are suggesting you'd need to have a redesign of everything from how arrays, strings and floating point numbers are represented in memory also then change file formats, various network protocols and re-introduce parallel connection methods between devices.
Good luck with that, we dont use PATA any more and its quite clear that serial connections are the future as they are low profile, cheap and get ever faster due to many little signalling tricks.
Also, HDD's, SSD's, DVD et al all address data as discreet blocks. Maybe this is what you are getting at as being able to change this so that we only need to modify the individual bits on the storage medium (once we have identified and changed the data in memory) that would certainly be better than reading and re-writing a whole block just to change a single character.
However, block based storage is very different from sequential storage like tape (unless the tape is formatted in blocks ad has a TOC). I cant see how you think its not.
You do, but only partially. While you have random access when reading (thanks to "memory mapping" it is both practical and performant), you don't while writing. There you are still treating it as if it were a tape recorder. ;-)
Cassandra was doomed to tell the truth and have nobody believe her. She didn't make posts on the Register suggesting that somehow an OS should allow you to insert stuff in the middle of a file where doing so will destroy the formatting on anything but the plainest of plain text.
> we’re still unable to take pieces out of files or add something at the beginning/in the middle. This is, because our systems were based on tape recorders.
I always set the tape speed jumper on new flash drives to 1⅞ inches per second for optimum performance.
I was in a meeting with the senior management of Everspin about 10 years ago and they were talking about their spin torque parts then as being 'in early beta'.
Glad to see they eventually figured out how to fix the problems to at least ship samples to some customers. One point, though - MRAM of all descriptions is quite expensive right now; hopefully mass production will start sooner rather than later and bring the prices down a bit.
It doesn't sound like it can be integrated into leading edge chips they're fabbing at 7nm EUV on bulk silicon. Too bad, it would probably have made a lot of sense in a phone form factor to put the NAND cache on your SoC with the storage controller block. It can't replace the NAND itself, it is nowhere near dense (i.e. cheap) enough, and putting it on a separate chip would eliminate both the speed and power advantages.
In what way is an alternative that requires 20-100F^2 cells and a more specialized process going to replace flash at all?
I wasn't talking about replacing flash, I was talking about using MRAM for an on-SoC flash cache, since that's where the controller/FTL is located. If you had to keep the cache on a separate chip you lose much of the advantage putting it on the SoC die would buy you.
Again: the idea is to enable a non-volatile memory technology that works/scales on the newer smaller geometries. Otherwise as designs migrate to newer technologies there will be no solution for non-volatile on-chip memory.
It is also a potential future solution for volatile memory too, for process nodes where classic memory elements may not reliably scale.
Since the start of computing, and since delay lines dropped out, storage has been a race between magnetic and electrostatic technologies, starting with magnetic drums and cathode ray screens.
Since then we've had magnetic cores, bubble memory, spinning rust and tape on the one hand, and EPROM and flash on the other.
This is the latest evolution of magnetic storage, with the advantage that unlike core it isn't destructive read and unlike bubble it doesn't involve moving domains around. It's really rather interesting.
One WEB say Samsung MRAM latency is 1 ns. or 1/30.000 that EEPROM latency but are only promises. Intel fiasco about 3Dxpoint promise 1000/1000, speed/endure about flash. For now all vaporware, we shall wait until end this special year 2019, ( new devices from world industry ) then we know more about NVM history.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
