sweet, wonder the cost to include this vs other "conventional" ways of getting the same thing?
can that Intel/Micron thing be used in the same fashion, if yes, why has not Intel done "similar" as I doubt they can sell every one of theirs for the prices they want/need to sell at, to use X as a write buffer vs Dram to do the same, I wonder if it is all positives or???
I think the footprint advantage is what they are going for here. Integrating the functionality of capacitors AND a memory buffer into a single significantly smaller component is a huge boon for NGFF drives.
Likewise, there will be no cost advantage because buffers and capacitors are substantially cheaper components.
Yes you can, with caveats. First, they only have 128Gbit(16GB) dies which are unnecessarily large for this purpose. Second, it'll end up being slower.
They'll need to split the space into two with 1GB being used as the buffer and the rest(15GB) being used as userspace caching. Then it'll become a slower SSD, but with 15GB Optane caching.
Potentially the mram will take up less space than the capacitors. The gallery Iinked shows a Samsung consumer 860 next to an enterprise 883 drive. The 6 super caps on the latter take up about as much PCB space as a flash chip or 2 ram chips. The MRAM chip shown in the article appears to be the same size as a standard DRAM; meaning that adding it and dropping the supercaps would free a bit of PCB space. If the MRAM could be stacked with the DRAM POP style it'd allow power loss protection without any extra board area. Probably not a huge issue in the 2.5" segment; but m.2 and various server focused high density stick drives are a lot more cramped for space.
(STT-)MRAM is much faster than 3D XPoint. It makes little sense to use 3D XPoint as a non volatile cache. 3D XPoint has a latency in the low μs (microsecond) range, while MRAM has a latency in the low to mid ns (nanosecond) range, depending on its type and capacity.
MRAM of a small enough size is quite faster than DRAM and even rivals SRAM, though it is about 6 times denser than the latter. Thus it can even be used as a non volatile CPU cache. (STT-)MRAM is ideal as an SSD cache.
When it comes to storage (and not memory), I have a feeling that a 128 gigabit 3D XPoint read/write cache would outperform a 1 gigabit MRAM cache simply because how little data can fit in a 1 gigabit cache.
XPoint is also a power whore. Although we don't have data on STT-MRAM yet, judging by its footprint, it likely doesn't use much more power than DRAM. A lot of the surface area of XPoint is partially for heat dissipation (and the packaging has a ton of interconnects)
everspin mram can use less power than dram as it does not need the extra refresh logic, the slowest 45 nm QSPI consumer version does 52Megabyte/s read and write 20 year retension and unlimited writes at 35ns latencys, if phisons uses the ip directly then they can also uses the faster sram type latencies directly and stack them into any wide HBM format they like....
I am really looking forward for MRAM (STT-MRAM, or even better SOT-MRAM) to come to consumer grade products : I believe it has the potential to be a key enabler of significant improvement in reducing latency to access code / data, and therefore significantly improve the end user experience (a bit like SSD brought much improvement compare to mechanical HDD)
Is write protection the ONLY thing they are using the MRAM for?
I'd have thought there'd be opportunity to use the MRAM to hold the FTL. That's mostly a read use-case, so the fact that MRAM has slower writes than DRAM (but, supposedly equal to rather faster reads) would be fine. And then you have the opportunity for cost saving (or at least cost parity) by dropping the DRAM...
The real problem, I guess, is that as outsiders we have no idea what the specs are for current ACTUALLY SHIPPING MRAM :-( (hint, hint, AnandTech...) We know what the theoretical profile is supposed to be in terms of read vs write performance, energy usage, density, granularity, cost, etc -- but we have no idea of the gap between that end point and what Everspin is shipping right now...
It is not really the Size of NAND SSD Drive that determines the cache. If you have a SSD operating at 1GB/s, 128MB cache isn't nearly enough, as that would mean 1/8 of second buffer. For drive that are now approaching 3GB/s, and more in the future, I think capacitor makes more sense.
If you can translate that state machine, with all the transitions, AND you have stats for average dwell times in each state, we’ll you’re way ahead of the rest of us. So inform poor dumb the rest of us of things like latencies (rd, write, what sort of variance do you see) and how much we might expect these to improve as memory controllers learn to optimize for the characteristics of this storage. Is there a significant read to write turn around time? So it makes sense to batch stores? Is there an important granularity(like pages) with lower latency to the equivalent of an open page? Are there similar trade offs as for DRAM for keeping pages open vs rapidly closing them? Is there a hierarchy of components (ranks, banks, pages, ...) each corresponding to a different type of bottleneck, so that maximum throughout (and minimum latency?) is achieved by spreading data across all these levels (by address bit shuffling or otherwise)? What are the performance characteristics of the wear-leveling?
Etc etc etc. None of this stuff Is NEARLY aaa obvious as you seem to think, at least not to me.
BTW, to other readers, the tech note on the Everspin web site discussing using MRAM on SSDs does, in fact, describe using MRAM to hold the FTL, thus removing the need for a DRAM; but seems to suggest that that’s a more demanding change than this first “write cache” change, so presumably gets implemented in the next gen of SSD controllers. (Maybe it also demands the next step larger of MRAM to be practical? though they don’t mention that.)
I think it's pretty great they are providing the information for free.
Demanding that they educate you for free, is a little over the top, don't you think?
Of course you could do a little research, answer those questions yourself and then publish an article for free: That would benefit you and perhaps some others as well.
The main issue is economy not MRAM vs. DRAM speeds: Were talking about operating Flash on SSDs not HPC.
So as long as MRAM is more expensive then DRAM, you only put data in it, that really benefits from the non-volatility. Read caches work just fine with DRAM, most parts of the FTL can be reconstructed after a power-fail, too, as long as the logs are secure. So the write buffer really is both on the critical timing path to acknowledge write completions to the host and for ensuring data consistency in case of a power failure.
Of course, MRAM also allows you to do more aggressive power management. These SSD controllers have embedded CPU cores with caches for code and data and if you design these caches in MRAM, saving the CPU state just means writing out the register file. Without MRAM you'd be stopping the clock but maintain enough power to hold CPU and cache state, because re-reading/re-constructing would require too much time (much like a power-fail recovery).
The latter case would require building the controller SoC on an MRAM enabled process, through, which sounds attractive for this use case, even if it's not part of part of this initial product, I believe.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
20 Comments
Back to Article
Dragonstongue - Thursday, July 25, 2019 - link
sweet, wonder the cost to include this vs other "conventional" ways of getting the same thing?can that Intel/Micron thing be used in the same fashion, if yes, why has not Intel done "similar" as I doubt they can sell every one of theirs for the prices they want/need to sell at, to use X as a write buffer vs Dram to do the same, I wonder if it is all positives or???
azfacea - Thursday, July 25, 2019 - link
i think the current mram chips are more expensive than capacitors to flush dram. but mram is improving a lot and maybe it will be cheaper eventuallySamus - Friday, July 26, 2019 - link
I think the footprint advantage is what they are going for here. Integrating the functionality of capacitors AND a memory buffer into a single significantly smaller component is a huge boon for NGFF drives.Likewise, there will be no cost advantage because buffers and capacitors are substantially cheaper components.
IntelUser2000 - Thursday, July 25, 2019 - link
You mean 3D XPoint/Optane?Yes you can, with caveats. First, they only have 128Gbit(16GB) dies which are unnecessarily large for this purpose. Second, it'll end up being slower.
They'll need to split the space into two with 1GB being used as the buffer and the rest(15GB) being used as userspace caching. Then it'll become a slower SSD, but with 15GB Optane caching.
DanNeely - Thursday, July 25, 2019 - link
Potentially the mram will take up less space than the capacitors. The gallery Iinked shows a Samsung consumer 860 next to an enterprise 883 drive. The 6 super caps on the latter take up about as much PCB space as a flash chip or 2 ram chips. The MRAM chip shown in the article appears to be the same size as a standard DRAM; meaning that adding it and dropping the supercaps would free a bit of PCB space. If the MRAM could be stacked with the DRAM POP style it'd allow power loss protection without any extra board area. Probably not a huge issue in the 2.5" segment; but m.2 and various server focused high density stick drives are a lot more cramped for space.https://www.anandtech.com/Gallery/Album/6812#5
Santoval - Thursday, July 25, 2019 - link
(STT-)MRAM is much faster than 3D XPoint. It makes little sense to use 3D XPoint as a non volatile cache. 3D XPoint has a latency in the low μs (microsecond) range, while MRAM has a latency in the low to mid ns (nanosecond) range, depending on its type and capacity.MRAM of a small enough size is quite faster than DRAM and even rivals SRAM, though it is about 6 times denser than the latter. Thus it can even be used as a non volatile CPU cache. (STT-)MRAM is ideal as an SSD cache.
Guspaz - Thursday, July 25, 2019 - link
When it comes to storage (and not memory), I have a feeling that a 128 gigabit 3D XPoint read/write cache would outperform a 1 gigabit MRAM cache simply because how little data can fit in a 1 gigabit cache.Samus - Friday, July 26, 2019 - link
XPoint is also a power whore. Although we don't have data on STT-MRAM yet, judging by its footprint, it likely doesn't use much more power than DRAM. A lot of the surface area of XPoint is partially for heat dissipation (and the packaging has a ton of interconnects)BMNify - Saturday, July 27, 2019 - link
everspin mram can use less power than dram as it does not need the extra refresh logic, the slowest 45 nm QSPI consumer version does 52Megabyte/s read and write 20 year retension and unlimited writes at 35ns latencys, if phisons uses the ip directly then they can also uses the faster sram type latencies directly and stack them into any wide HBM format they like....DanNeely - Thursday, July 25, 2019 - link
You included figure 2 twice.Diogene7 - Thursday, July 25, 2019 - link
I am really looking forward for MRAM (STT-MRAM, or even better SOT-MRAM) to come to consumer grade products : I believe it has the potential to be a key enabler of significant improvement in reducing latency to access code / data, and therefore significantly improve the end user experience (a bit like SSD brought much improvement compare to mechanical HDD)name99 - Thursday, July 25, 2019 - link
Is write protection the ONLY thing they are using the MRAM for?I'd have thought there'd be opportunity to use the MRAM to hold the FTL. That's mostly a read use-case, so the fact that MRAM has slower writes than DRAM (but, supposedly equal to rather faster reads) would be fine. And then you have the opportunity for cost saving (or at least cost parity) by dropping the DRAM...
The real problem, I guess, is that as outsiders we have no idea what the specs are for current ACTUALLY SHIPPING MRAM :-( (hint, hint, AnandTech...)
We know what the theoretical profile is supposed to be in terms of read vs write performance, energy usage, density, granularity, cost, etc -- but we have no idea of the gap between that end point and what Everspin is shipping right now...
IntelUser2000 - Thursday, July 25, 2019 - link
1Gbit is too small, which explains the specialized use case for the device.Most SSDs need 1GB of DRAM for 1TB of NAND.
ksec - Thursday, July 25, 2019 - link
It is not really the Size of NAND SSD Drive that determines the cache. If you have a SSD operating at 1GB/s, 128MB cache isn't nearly enough, as that would mean 1/8 of second buffer. For drive that are now approaching 3GB/s, and more in the future, I think capacitor makes more sense.hojnikb - Thursday, July 25, 2019 - link
DRAM cache is not used as a buffer, but only for FTL. As such, it generally needs 1GB of space for every 1TB of flash.Billy Tallis - Thursday, July 25, 2019 - link
Everspin's website has datasheets for the current 256Gb MRAM parts, including full timing information. It's not much of a mystery.name99 - Thursday, July 25, 2019 - link
If you can translate that state machine, with all the transitions, AND you have stats for average dwell times in each state, we’ll you’re way ahead of the rest of us. So inform poor dumb the rest of us of things like latencies (rd, write, what sort of variance do you see) and how much we might expect these to improve as memory controllers learn to optimize for the characteristics of this storage.Is there a significant read to write turn around time? So it makes sense to batch stores?
Is there an important granularity(like pages) with lower latency to the equivalent of an open page?
Are there similar trade offs as for DRAM for keeping pages open vs rapidly closing them?
Is there a hierarchy of components (ranks, banks, pages, ...) each corresponding to a different type of bottleneck, so that maximum throughout (and minimum latency?) is achieved by spreading data across all these levels (by address bit shuffling or otherwise)?
What are the performance characteristics of the wear-leveling?
Etc etc etc. None of this stuff Is NEARLY aaa obvious as you seem to think, at least not to me.
BTW, to other readers, the tech note on the Everspin web site discussing using MRAM on SSDs does, in fact, describe using MRAM to hold the FTL, thus removing the need for a DRAM; but seems to suggest that that’s a more demanding change than this first “write cache” change, so presumably gets implemented in the next gen of SSD controllers. (Maybe it also demands the next step larger of MRAM to be practical? though they don’t mention that.)
abufrejoval - Friday, July 26, 2019 - link
I think it's pretty great they are providing the information for free.Demanding that they educate you for free, is a little over the top, don't you think?
Of course you could do a little research, answer those questions yourself and then publish an article for free: That would benefit you and perhaps some others as well.
abufrejoval - Friday, July 26, 2019 - link
The main issue is economy not MRAM vs. DRAM speeds: Were talking about operating Flash on SSDs not HPC.So as long as MRAM is more expensive then DRAM, you only put data in it, that really benefits from the non-volatility. Read caches work just fine with DRAM, most parts of the FTL can be reconstructed after a power-fail, too, as long as the logs are secure. So the write buffer really is both on the critical timing path to acknowledge write completions to the host and for ensuring data consistency in case of a power failure.
Of course, MRAM also allows you to do more aggressive power management. These SSD controllers have embedded CPU cores with caches for code and data and if you design these caches in MRAM, saving the CPU state just means writing out the register file. Without MRAM you'd be stopping the clock but maintain enough power to hold CPU and cache state, because re-reading/re-constructing would require too much time (much like a power-fail recovery).
The latter case would require building the controller SoC on an MRAM enabled process, through, which sounds attractive for this use case, even if it's not part of part of this initial product, I believe.
flgt - Thursday, July 25, 2019 - link
Everspin really needs some good financial news.