Intel Confirms that FinFET MRAM is Production Ready

AlphaAtlas

AlphaAtlas

[H]ard|Gawd
Staff member
Joined
Mar 3, 2018
Messages
1,713
Late last year, EE Times published a report claiming that Intel was already shipping MRAM products to undisclosed customers. At the time, Intel only confirmed that their MRAM was "production ready" and didn't elaborate any further. But now, the news outlet says that Intel presented a paper on their embedded MRAM at the International Solid-State Circuits Conference. The fast, non-volatile 7Mb memory arrays reportedly achieve "10-year retention at 200C" and have "demonstrated write endurance of more than 1E06 cycles and read disturb error rate of more than 1E12 cycles." While EE Times calls the 22FFL process the MRAM arrays are built on a "22nm" process, semantics in the world of semiconductors are fuzzy, and Wikichip believes that 22FFL actually has more in common with Intel's 14nm processes. "Analysts" still believe that Intel is shipping products with MRAM, but the chip company hasn't elaborated on any of them yet.

According to Intel's ISSCC paper, each 0.0486-um2 transistor to one magnetic tunnel junction (1T1MTJ) MRAM bit cell is 216 x 225 nm2, with two polysilicon word lines. The tunnel-magneto-resistance ratio of the MTJs is 180% at 25C, with a target device-critical dimension between 60 nm and 80 nm. Wei said that the eMRAM design is also tolerant of wide variations in supply voltage. The design achieves a 4-ns read sensing time at 0.9 V but is also capable of 8-ns read sensing time at 0.8 V, she said... In a separate ISSCC paper presented Tuesday, Intel also described the development of resistive RAM (ReRAM) as a low-cost option for embedded non-volatile memory for SoCs used in IoT and automotive. The embedded ReRAM technology - also implemented in a 22-nm FinFET process - demonstrate what the company says is the smallest and highest-density ReRAM subarray and material innovations to allow low-voltage switching without impact to transistor reliability.
 
Doesn't this compete with Optane? If so they might not have any incentive to release a product.

Also had to look up whether Optane used MRAM. It uses 3D XPoint which one source says is phase change memory.
 
MRAM is not new, and to be honest the specs that Intel has provided don't look competitive with existing MRAM products. Everspin is shipping 1Gb MRAM chips since Dec 18 for example on 28nm. The main difference is Intel embedding it in other designs which likely hasn't been done before, but it is difficult to ascertain how significant that is given MRAM doesn't require any particularly exotic process tech (Everspin's MRAM is made by global foundries). Looking at the basic data provided, it appears Intel is getting roughly 20Mbit per mm2. DRAM is about 400Mbit per mm2 currently, so MRAM has a long way to go before it can take on DRAM in density, and unlike HDD to SSD, both technologies scale with process improvements (which are plateauing).
 
Corvette said:
Doesn't this compete with Optane? If so they might not have any incentive to release a product.

Also had to look up whether Optane used MRAM. It uses 3D XPoint which one source says is phase change memory.
Click to expand...

No, 3D X-Point looks exactly like ReRAM. Just have a look at the tech documents. It's the same basic cell structure as everyone else's in-development ReRAM, but Intel's proprietary tweaks.

MRAM will never have the density of ReRAM, let-alone MLC Flash. It wastes a ton of space storing the magnetic charge, even with spin designs. But it should have vastly better powered-off data retention time (ReRAM is similar to flash).

So these target two different markets here. Perfectly possible for a giant like Intel to be working both.
 
Last edited:
MRAM is a nice EEPROM replacement at this point and not commercially viable for much else. It’ll never reach flash densities so an NVDIMM is probably the best case scenario for it.
 
KD5ZXG said:
https://www.everspin.com/family/emd3d256m

iNTEL 7Mb vs Everspin 256Mb. What's iNTEL offering to get excited about?
Hell, I bought Everspin 16Mb MRAM almost 8 years ago.

Geni said something about 1Gb, I couldn't find any reference to such a part.
Not saying it doesn't exist...

Though I did just find something I hadn't seen before:

https://www.everspin.com/embedded-mram-process
Click to expand...

Um, you are comparing a sub-array to a multi-array part. The Intel design is basically 10Mb/mm^2. Larger memory devices are always made up of smaller sub-arrays replicated to achieve the required capacity. The existing 256mb everspin part is likely in the range of 25-50mm^2 which would put it around 5-10 Mb/mm^2 all up
 
So anyways, I got this old Everspin 35nS 16Megbit MRAM. Brainstorming a long time on various ALU schemes it might hold. Lately I'm leaning toward 7bits with a flag as better fit than 8bits with flags by separate lookup. Giving 128 functions: multiplication, division, square root, and cosine to 14 or 28 bits of precision. Way beyond the usual ADD/AND/SHIFT. With plenty of space leftover for 256Kx8 ROM, and 1Mx8 RAM. All on one chip I already own.

Lookup result temporarily stores in 74AC373 latch (3.3V compatable), then writes back next half cycle. Or pass to latches that provide external breakout for registers. Thinking far too many of these will be needed for DIP stackups with blue-wired chip select. Also the matter of busses with too much fanout.

Could replace an impossibly large register file with four small MRAMs (each 32Kx8). Providing 32bits of control signal back to the main MRAM + a few extra lines for purposes to be defined later. Fill the excess space with microcode tables. Use only some reasonable quantity of discreet latches for breaking out fetched instruction and microcode counter. Here again, MRAM can seamlessly serve more than one combined ROM/RAM purpose. As with the ALU, splitting ROM/RAM function exactly in half makes write protect a simple address bit.

Each memory location then holds either 8 bits of data, or 7bits with a flag. Registered locations expose flags for branching. 4 banks of 16Kx8 (the half not dedicated to microcode) could easily expose a crazy number of registers, output in any combo 32 bits wide. Fully mapping all of it could require very long instructions, slow to fetch. Registers were not intended just as breakouts for arguments and indexes, but also as a shorthand subset of addresses. What better use might be made of excess register space, inconvenient to map to short instructions, a stack or two perhaps?

Little as possible discreet random logic, mostly lookups in multipurpose MRAM. Machine state inherently preserved on power cycle, interrupt, or task switch. Might even dumb the program counter down to 7 or 8 active bits (handle the rest passively). Speed repetitive counting to a single lookup. By the time I could draw you a coherent picture, the whole plan will likely change again. Lost count how many times I've edited just this one post. Desktop overflowing with years of half-baked .txt files.
 
Last edited:
You must log in or register to reply here.
Back
Top