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
Feb 28, 2021
Using Cadence ® Specman ® Elite macros lets you extend the e language '”€ i.e. invent your own syntax. Today, every verification environment contains multiple macros. Some are simple '€œsyntax... [[ Click on the title to access the full blog on the Cadence Comm...
Feb 27, 2021
New Edge Rate High Speed Connector Set Is Micro, Rugged Years ago, while hiking the Colorado River Trail in Rocky Mountain National Park with my two sons, the older one found a really nice Swiss Army Knife. By “really nice” I mean it was one of those big knives wi...
Feb 26, 2021
OMG! Three 32-bit processor cores each running at 300 MHz, each with its own floating-point unit (FPU), and each with more memory than you than throw a stick at!...

featured video

Designing your own Processor with ASIP Designer

Sponsored by Synopsys

Designing your own processor is time-consuming and resource intensive, and it used to be limited to a few experts. But Synopsys’ ASIP Designer tool allows you to design your own specialized processor within your deadline and budget. Watch this video to learn more.

Click here for more information

featured paper

The Basics of Using the DS28S60

Sponsored by Maxim Integrated

This app note details how to use the DS28S60 cryptographic processor with the ChipDNA™. It describes the required set up of the DS28S60 and a step-by-step approach to use the asymmetric key exchange to securely generate a shared symmetric key between a host and a client. Next, it provides a walk through on how to use the symmetric key to exchange encrypted data between a Host and a Client. Finally, it gives an example of a bidirectional authentication process with the DS28S60 using an ECDSA.

Click here to download the whitepaper

Featured Chalk Talk

Magnetics for High Voltage

Sponsored by Mouser Electronics and Bourns

With today’s trend toward ever-increasing voltages in energy systems, choosing the right transformer for the job has become an engineering challenge. High voltages demand careful attention to insulation, clearance, and creepage. In this episode of Chalk Talk, Amelia Dalton chats with Cathal Sheehan of Bourns about choosing magnetics for high-voltage applications.

More information about Bourns Magnetics for High Voltage Applications