feature article
Subscribe Now

A Non-Volatile Middle Ground

Few-Times-Programmable Memory from Virage and… um… Virage

A few weeks ago we started a look at Logic Non-Volatile Memory (Logic NVM) options. These are non-volatile memories intended for embedding in SoCs using only standard logic processes instead of the more complicated processes designed to optimize large quantities of memory. We looked at one-time programmable (OTP) versions, which, not too surprisingly, can be programmed only once. We also looked at multiple-time programmable (MTP) versions, which can in general be programmed 100,000+ times while maintaining a data retention time of 10 years or more even on the 100,000th programming.

But there’s another flavor – or category with a couple flavors – that lies in between OTP and MTP, called few-times programmable (FTP). This is intended for applications where you really want to be able to make changes, but you’re not going to need to do it tons of times. One obvious such application is for code that may need to be patched. Unless you’re way out of control, you’re not going to need to patch your code 100,000 times. FTP memories can generally be programmed 10s to 100s of times; the limiting factor may be technology, or it may be architecture, depending on how the memory is implemented.

Conceptually, there are two ways to approach the problem. I should state here that, commercially, “FTP” may not be used to describe both of these, but I’m going to do so – more on that later. One approach is to make changes to the cell such that for a size benefit, you trade off the 100,000-cycle endurance. The other is to make architectural modifications to allow some “redos.” One obvious – if inefficient – way to do the latter is just to have several OTP memories that all look the same, along with a demux/mux pair on the input and output (and some way of configuring the demux/mux on power-up, either with a non-volatile cell or a configuration stored in external memory). If there are, say, four memories, then you start with the first one, program it, and, if you need to make a change, you use the second one instead and configure the demux to access not the first but the second and the mux to route not the first one’s outputs, but the second one’s.

Given such a setup, you would have a four-time programmable memory. And the space taken would be 4x what would be required for a single OTP memory (plus demux, mux, and configuration), so this would make sense only if an MTP implementation were greater than four times the size of an OTP memory. This reasoning gets out of hand if you want anything more than a few rewrites, so this example is more illustrative than practical.

A more limited approach is to use mapping, oversizing the OTP memory with what essentially become redundant rows, and when a block of memory has to change, that block gets remapped. So instead of replicating the entire memory just because a few bits change, you leave the bulk of the original programmed memory where it was and remap only a smaller portion that contains the changes. The tradeoff here is that the remapping logic is much more substantial than just a demux and a mux, so the savings in memory size must more than make up for the increase in logic.

Room to grow

Virage has actually taken this approach one step further with what they call their emPROM. This is largely targeted towards microcode implementations: embedding the memory means the code is secure (since it can’t be tapped between an external memory and the SoC). But the amount of memory needed can really hurt the die size if strictly done using an MTP logic NVM technology. On the other hand, using OTP would allow no patching, which is pretty much a non-starter.

So what they do is provide a main ROM code section, a smaller MTP section, and then logic to handle the remapping and other management logic (which together constitute an “emPROM processor,” part of which is user configurable). This is an IP offering, so the details of memory sizes and configuration can be tuned by the user. The ROM section would be programmed during chip fabrication by a mask that creates the “factory” image. Any changes to that would be implemented in the MTP section of the memory, with attendant changes to the mapping. The ROM is extremely small – the smallest possible cell – so sizes from 16 Kbits to 16 Mbits are supported, with the MTP section being 16K or below.

Theoretically, OTP memory could be used instead of ROM if the initial image were desired to be programmed during test or even in the field. OTP cells are bigger than ROM cells, and there are other considerations, but the biggest practical matter is that Virage doesn’t sell OTP; in fact, they sell against it. So there isn’t a version of the emPROM with an OTP bulk memory.

Because the patch section is MTP, it’s theoretically possible that a subsequent change to an already-changed portion of code could be written over the prior change without changing the mapping. But more typically, each patch will take more memory from the MTP section, gradually using it up until it’s full, after which you don’t get to program any more times.

I’ll take a half-order

The other approach to creating an FTP was used by Impinj – which means it is also now a Virage offering, since Virage bought Impinj’s memory IP business. You may recall from the last article that MTP cells tend to be built using a differential configuration – essentially two bits per actual bit of memory, programmed in opposite states– in order to improve endurance and data retention. An immediate savings can be had by moving from a differential cell to a single-sided cell – you basically lose half the transistors and save half the space. The tradeoff is the endurance.

Each programming pass causes a bit of damage to the oxide that’s supposed to hold the charge in place, making it easier for it to leak out. The differential cell is more robust as far as leakage is concerned because it’s self-referencing: if one of the two sides of the memory cell leaks, it drifts, but the reference point is the halfway-between-the-two-sides point, so when one side drifts, the read point also drifts. Using fake bogus made-up numbers (did I mention that these numbers bear no resemblance to any physical entity?), if a perfect cell has its sides programmed to values -2 and 2, then the reference point is 0, half-way between, and there is a margin of 2 between the programmed cell value and the reference point.

If the -2 side gradually leaks away to -1 (leakage moves it towards 0), then if the reference point stayed at 0, the margin would shrink to 1. But because of the differential cell, the reference point stays at the halfway point, which is now 0.5 (the midpoint between -1 and 2), and the margin is 1.5.

Once you give up the differential cell, you no longer have this halfway point that you can use as your reference. So now a fixed reference point has to be included (so there’s some extra circuitry for that), and all bits reference that point. If one of those bits drifts, there’s no forgiveness – the reference point stays stubbornly fixed. (OK, it’s supposed to, anyway.) This means less robustness against leakage, meaning that the cell can tolerate less damage (which increases leakage), meaning that you can’t program it as many times without the leakage causing read failures. Hence, a few-times-programmable memory. The payoff is that it uses roughly half the die area of its MTP cousin.

Now, this might make the cell sound unreliable, but in fact all it means is that the cell can tolerate fewer program cycles. As long as you stay below the lower rated programming cycle limit, it’s as good as an MTP cell.

It will be interesting to see the uptake of these two technologies since they’re now both offered by the same company. There may be niches where each works best, or one may end up crowding out the other. Given the general American corporate impatience and inability to process nuance (this is not a specific characterization of Virage; maybe they’re different), my bet is that one will eventually win even if there are applications favoring the loser. Two products lines sharing too many traits tends to form a notoriously unstable product configuration. I have noticed that the term “FTP” is absent on the emPROM materials, so that term might be leveraged in an attempt to create a greater distinction for the ex-Impinj technology. And in fact, if all cumulative changes made to an emPROM design could fit within the MTP section, then strictly speaking, it’s an MTP device, not an FTP device; this scenario seems theoretically possible but unlikely. So I’m being stubborn and extending the term to both technologies, since, by practical definition, both are few-times programmable.

Leave a Reply

featured blogs
May 14, 2021
Another Friday, another week chock full of CFD, CAE, and CAD news. This week features a topic near and dear to my heart involving death of the rainbow color map for displaying simulation results.... [[ Click on the title to access the full blog on the Cadence Community site....
May 13, 2021
Samtec will attend the PCI-SIG Virtual Developers Conference on Tuesday, May 25th through Wednesday, May 26th, 2021. This is a free event for the 800+ member companies that develop and bring to market new products utilizing PCI Express technology. Attendee Registration is sti...
May 13, 2021
Our new IC design tool, PrimeSim Continuum, enables the next generation of hyper-convergent IC designs. Learn more from eeNews, Electronic Design & EE Times. The post Synopsys Makes Headlines with PrimeSim Continuum, an Innovative Circuit Simulation Solution appeared fi...
May 13, 2021
By Calibre Design Staff Prior to the availability of extreme ultraviolet (EUV) lithography, multi-patterning provided… The post A SAMPle of what you need to know about SAMP technology appeared first on Design with Calibre....

featured video

Industry’s First USB4 Silicon Success

Sponsored by Synopsys

USB4 offers up to 40Gbps speeds for incredibly fast connections. Join Synopsys to see the first demonstration of USB4 IP in silicon, along with real TX eyes for DesignWare USB4, DisplayPort, and USB 3.x IP.

Click here for more information about DesignWare USB4 IP

featured paper

Use Configurable Digital IO To Give Your Industrial Controller the Edge

Sponsored by Maxim Integrated

As factories get bigger, centralized industrial process control has become difficult to manage. While there have been attempts to simplify the task, it remains unwieldy. In this design solution, Maxim briefly reviews the centralized approach before looking at what potential changes edge computing will bring to the factory floor. They also show a digital IO IC that allows for smaller, more adaptable programmable logic controllers (PLCs) more suited to this developing architecture.

Click to read more

featured chalk talk

Time Sensitive Networking for Industrial Automation

Sponsored by Mouser Electronics and Intel

In control applications with strict deterministic requirements, such as those found in automotive and industrial domains, Time Sensitive Networking offers a way to send time-critical traffic over a standard Ethernet infrastructure. This enables the convergence of all traffic classes and multiple applications in one network. In this episode of Chalk Talk, Amelia Dalton chats with Josh Levine of Intel and Patrick Loschmidt of TTTech about standards, specifications, and capabilities of time-sensitive networking (TSN).

Click here for more information about Intel Cyclone® V FPGAs