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.
