NV on-chip memory?

Yes.

Can you clarify - would this need Supra Voltages/Currents, or can the FPGA program itself, while running. ( eg could an NV event log be created ? )

First one is easy, X = 0 :)

An interesting question.

From a wider industry perspective, there is a trend in the Microcontroller sector, to offer MASK devices, where a couple of years ago the party line was 'we will now only make FLASH'.

This must be driven by a number of factors, and clearly customer demand, because of

** MASK is always going to be lower cost (fewer process steps, and testing) ** Zero risk of field bit erasure ** No programming needed at customer end. ** Some apps stipulate that high voltage must be needed for program, so they want to _guarantee_ errant software cannot jump into the FLASH loader Block erase routines, for example :)

Designers love Flash, because they can change it easily, but there are many products that are code-stable, and the bean-counters prefer the lowest cost options.

So, back to your Cheap OTP memory in FPGA question ?

First step would be to give every device a 128 bit unique ID, that could be used for seed, and ID usage. Users would access that 'for free' in their present flows.

Next step is more questions : What is the yield of this memory ? All OTP memory has failures, so what does the user do, if this occurs - remove the FPGA from a expensive PCB ?

Speed and Width of the memory ?

Can it be easily swapped for (say) off chip NV memory, or on Chip RAM ?

Market Model here is then the same as for MASK uC. Product development is using NV memory, and when proven stable, the lower price option is chosen. This applies to both CODE and FPGA CONFIG memory spaces.

For configuration data, I would guess the cost of this memory would start to be significant, which would push up the device variant price, and impact those users who never used this feature.

I would imagine, provided it was easy to develop with, that OTP memory would expand the usage of the simplest soft processors, for state engines, and stable-code layers.

Quite small OTP memory could be usefull here,

I'm missing something. How can data be both secure and useful? If I can read it back out to use it, clearly the bad guy can too. It might take him a while to write some code to get it. That doesn't seem like a big deal compared to the recent discusions on extracting the encryption key for the configuration bit stream.

Same general idea for secure code. You might be able to make that secure if you had a dedicated memory that was only good for code. But that seems against the general idea of flexibility that makes FPGAs so interesting. Besides, it would probably be a pain to debug - or the debugging tools could be used to read the code memory.

One time secure configuration data might be interesting. I'm not sure how much I would pay for it. Not much for anything I can think of right now.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Let me first say thank you for your responses. To address some of the questions / comments: I realize that not everyone will extract the same application or value from the on-chip NV memory, however, since it has the potential to provide or support different applications, general enough value may be justified for inclusion. Answers / Comments for Jim and Hal: a. bad bits: built in ECC would make bad bit transparant to the user

b. speed = assume approximately 25ns access time

c. width = flexible, 16/32/64 bit

d. secure code storage would come by two assumptions: i) on-chip processor preventing external need to access the memory. ii) readback via JTAG etc of Memory would be programmed as disabled by the user

e. on-chip charge pumps require no special external voltage supply

f. user application would be able to log/write data to NV memory for storage

g. external applications could read NV data too, but you obviously loose security

h. OTP = nonerasable

i. no tradeoff with NV and Ram like functionality - it would be a standard feature, not swappable block within the silicon family

j. yes for non secure, it would enable integration into the FPGA of on-board NV data for some applications (mature s/w code for example). Realize that also for some applications, you can create a sense of "virtual" unlimited multiwrite capability. To demonstrate what I mean by Virtual multi-write, I'll use the following example. Let's say that you know you may need to write 10,000 maximum lifetime events at

100 bits data each but do not need to keep history for more than 16 events. As a designer, you could buy a tiny block of flash or EEPROM of 1.6kbits and keep writing over the older events. Or, with OTP, you could simply purchase enough OTP memory to store the entire lifetime worth of events. Many applications that store NV data can quantify the lifetime of storage from a practical specification. One example, Televisions need to store user configuration (like: color, tint, favorite channels etc), and need to provide the user with unlimited adjustments of this data. However if you make some assumption, the design can calculate an upper limit of needed storage. For example, lets say 512bits stored, TV life is 20 years. I would venture to guess that if you assumed that data storage would occur Max once a day for each of 20 years, you would be happy to remove the $1 EEPROM from the board as long as the on-chip cost of the NV block was less. 20yr*512b*365days = 7Mbit total

Any other creative thoughts on how this could be used would be appreciated.

Thanks.

Message 2 > quick survey...

Yes.

Can you clarify - would this need Supra Voltages/Currents, or can the FPGA program itself, while running. ( eg could an NV event log be created ? )

First one is easy, X = 0 :)

JIM GRANVILLE POSTED: An interesting question.

From a wider industry perspective, there is a trend in the Microcontroller sector, to offer MASK devices, where a couple of years ago the party line was 'we will now only make FLASH'.

This must be driven by a number of factors, and clearly customer demand, because of

** MASK is always going to be lower cost (fewer process steps, and testing) ** Zero risk of field bit erasure ** No programming needed at customer end. ** Some apps stipulate that high voltage must be needed for program, so they want to _guarantee_ errant software cannot jump into the FLASH loader Block erase routines, for example :)

Designers love Flash, because they can change it easily, but there are many products that are code-stable, and the bean-counters prefer the lowest cost options.

So, back to your Cheap OTP memory in FPGA question ?

First step would be to give every device a 128 bit unique ID, that could be used for seed, and ID usage. Users would access that 'for free' in their present flows.

Next step is more questions : What is the yield of this memory ? All OTP memory has failures, so what does the user do, if this occurs - remove the FPGA from a expensive PCB ?

Speed and Width of the memory ?

Can it be easily swapped for (say) off chip NV memory, or on Chip RAM ?

Market Model here is then the same as for MASK uC. Product development is using NV memory, and when proven stable, the lower price option is chosen. This applies to both CODE and FPGA CONFIG memory spaces.

For configuration data, I would guess the cost of this memory would start to be significant, which would push up the device variant price, and impact those users who never used this feature.

I would imagine, provided it was easy to develop with, that OTP memory would expand the usage of the simplest soft processors, for state engines, and stable-code layers.

Quite small OTP memory could be usefull here, >It would be very secure (anti-copy) for:

Would it slow down the fab or up the cost?

There is already a more secure mechanism for this: SRAM-based encryption keys used to load encrypted bitfiles. That mechanism can be used to bootstrap a large non-volatile store, with a keystone of the SRAM-based encyption key which is probably significantly harder to reverse/crack than on-chip static bits.

Thus the "savings" by putting it on-chip are not security, but the cost savings of not needing a large external Flash PROM.

--
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Since this is Horizon gazing, what about looking into FPGA+MRAM - then you can offer SRAM to all users, and do not have to do a RAM/OTP die trade off - plus it is much easier to explain to users. [FPGA designers are not always the most hardware literate :) ]

For an example of MRAM see

What about a bad row/column select line - or is enough fringe test memory included to test all array access lines ?

Any Icc projections ? [ROM is usually quite low power]

Why stop at 64 wide ? One edge on-chip memory gives is 'free width', and that can translate to lower power.

Any values/estimates on write times / write energies / Block sizes ?

What about Read-While-Write - which is a common drawback in FLASH.

But selectively, one would hope ?

I was meaning more Software than Hardware - the issue is development, and early production, where users need to not have ROM. That may mean a bigger device (with the extra SRAM), and a re-compile, or external NV memory.

There is also potential here for power saving, as external memory will always be width constrained to save pins, plus have all the BUS capacitance. Internal ROM can be wider, so use a lower clock for the same BUS bandwidth.

Nicholas Weaver wrote: > There is already a more secure mechanism for this: SRAM-based > encryption keys used to load encrypted bitfiles. That mechanism can > be used to bootstrap a large non-volatile store, with a keystone of > the SRAM-based encyption key which is probably significantly harder to > reverse/crack than on-chip static bits. >

That's true for bitstreams, but not as easy for external code. I can see an application where the user defines a 'Rom BUS Scrambler' that is used to load the external memory, and then reverse the scramble on read. See the Dallas secure Microcontroller families. Boot load code could be 'password zipped', where more time is tolerated to unpack, and shift to the external memory. So you get medium levels of security, with low cost (?) silicon, and not needing too special design flows.

-jg

One thing we are striving to do, in order to keep cost minimal, is to stay away from non standard CMOS processes. MRAM although by itself shows huge promise for density/speed/cost, will add non-linear cost to SoCs due to non-standard process needed and thus premium for the entire SoC, not just the MRAM portion. Good idea though. Let's assume a technology has been identified that does meet this goal for the assumptions I originally described.

Let's assume the user will not need to be concerned about this as it will be handled by the fpga vendor both in write-by design, test modes and testing.

Assume: Icc Standby = ~ 20uA Icc Active = similar to on-chip/embedded sram (similar sense amps etc)

There would be a trade-off of standby versus active power reduction which is dependent on width. Wider = higher standby power but lower active due to bandwidth.

As you allude, NV memory often does have assymettrical write/read times. A goal of ours is to support no slower than 50us per write word. At

64bit word, this is 1.28Mkbps. I believe many applications will be immune from write time consideration since many will preprogram the data. In circuit logging may consider this but due to OTP and finite size (~10mbit), I assume 1.28mbps is fine? What do you think? As far as write power, a goal is What about Read-While-Write - which is a common drawback in FLASH.

Not sure I understand your read-while-write - does this imply dual port? IF so, for cost considerations and area optimization, we are only anticipating single port NV blocks.

Security would depend on the data and application? Of course, the user can implement an DES/AES encryption scheme and use a NV OTP Key on chip thus enabling quite secure data transfer. However, if the data is program memory or something that can't be encryted, then security is less.

Nicholas - please see below responses. Thanks.

See response to Jim - our goal is a standard fab process so cost would simply be driven by it's area.

Just to point out, the mechanism you are referring to for SRAM based devices require the programming of NV memory to hold this mentioned security Key. ALthough the encryption is super strong from the data perspective, analyzing the physical NV memory currently being used (EEPROM/EPROM/or FLASH) is not very difficult to extract the Key and thus crack the encrypted data. This NV technology adds manufacturing premium to the whole wafer cost, which is traded off for the value of the feature. We are looking into removing this process premium via the NV technology discussed in the thread. Also, the memory technology being discussed is actually undetectible and thus can not be cracked. Does this sound good to anyone? What applications do users envision needing true anti-piracy/copy of the actual FPGA configuration/functionality? I'll probably start another thread on this.

So, based on above paragraph, savings is realized in both external NV integration onto the chip and ultimate Security of data via encryption and security of the actual Key.

Thanks.

Guy,

Undetectable?

Go fool somebody who can be easily fooled.

I have been told that any NV technology can be cracked by techniques available today.

I have even been told that reading out the state of our battery backed key memory can be done today.

The reason why I do not believe the latter, is that they have to do it, while keeping the battery backed memory power ON.

To de-cap the device, and remove the flip chip from the package, all the while retaining power to the BB RAM bits, and then going through 11 layers of metal is something I would like to see! (Perhaps a determined attacker with an infinite budget could do it, though....can never be absolutely sure).

Otherwise, to determine the state of a NV technology by electron microscope, electron microscope charge probing, ..... (put in your favorite fancy tool here) is considered to be a 'known' method of attack.

That is why our federal government does not even consider the use of non volatile storage for keys in their standard for equipment (FPIS-41).

Let alone something that has to be really secure (which has to have even better methods for protection built into it).

So assuming a determined attacker (which you must assume, as assuming an average attacker is just wishful thinking) you can not seriously make a statement like you just did.

And any claim of obscurity is also just wishful thinking. Any secret that prevents someone from understanding the security is automatically assumed to be know to a determined attacker. The government also tells you that. Go read about how obscurity fails. All the time. Over and over (and folks still do not learn).

That is why we are FPIS-41 compliant. That way, there is no obscurity. AES 256 is well known, well understood, we use battery backed (one industrial lithium coin cell lasts for a lifetime powering up to 8 devices, literally from -40C to +100C) RAM for the keys, and keys go away when power is removed .

Since the method you propose does not conform with FIPS-41, why do you bother at all to use it for anything to do with security? Why not just call it a 'baby gate' to prevent 'domestic accidents'.

Don't bother to argue with me. It is the NSA, CIA, etc. you would have to convince.

Aust> Nicholas - please see below responses.

Post Script:

By the way, a number of folks mistakenly belive that our FPGAs 'require' batteries. (??!!!???HUH???)

That is not true.

You only require a battery if you want to keep the keys alive when power is removed when using the encrypoted bitstreams.

If you do not use encryption, then you should leave the BBRAM Vcc pin alone.

As for NVRAM, there are lots of useful things it would be nice to have it there for.

Since there is perfectly good NVRAM processes available for larger (older) transistor technologies, there are lots of products that are available with those features.

For us 'leading edge' FPGA types, we 'only' have standard CMOS process available.

Austin

It was suggested that I provide a disclosure. It should not be assumed that I am affiliated with Altera or that Altera has intent to create features as discussed in this thread. The name and email you see on the posting is a known mechnaism through which I was able to obtain New Group access.

Either way, thank you for continuing the discussion.

Guy,

Either you represent Altera, or you do not.

There is no in between.

I do not have that luxury, and neither do you.

State who who represent.

You do more damage to Altera by posing as you do.

If you wish to remain anonymous, get a yahoo.com email account.

If you wish to do market research in Altera's name (or by their leave), fine; say so. If you are not doing market research in Altera's name (or by their leave), don't use it.

Austin

"Fool me once, shame on you. Fool me twice, shame on me."

Understood, this was a tad tongue in cheek... (but you will need to watch MRAM, longer term)

Wider words would increase the bit rate, but would need larger charge pumps. > 1Mbps, means 1-2 seconds of storage, so peak speed is not likely to bother many designs. ie if someone really wants 1Mbps they probably have other storage.

NV Write memory would be more use for Audit trail/timetag/blackbox/ and in some cases environment or fault logging.

With the wide paths, you could use edge-time compression, and I presume a RAM FIFO could go in front of the NV Write, so the average rate might be 20K edges/50us per 64 bit stamp, but short pulses/bursts could be captured at much higher peaks, probably to the ~250MHz chip speed ?

No. In FLASH one problem is that while writing, the same block cannot be sensibly data-read [HV write lines vs LV read sense].

Thus you often see split banks, so you run code from one bank, to write to the other bank & vice versa. Some newer devices 'stall the core' for the Twp, which gives cleaner software.

With a Twp of 50us, it sounds like you will not be able to read from the same block for that time. You could add the 'stall/wait' HW signal, so any soft uC would not try to read for that time ?

Summary: Unless you hit a hard-ceiling, I would not limit the access to

16/32/64 bits - wider comes for free inside a FPGA, and there will be apps we have not thought of.

I also see NV memory as opening more scope for smaller/tiny Soft uC. By going op-code sequential, you can save FPGA resource on the slower stuff, and keep it for the fast stuff, where it really matters.

eg older design approach is to have a fast uC, running interrupts to handle small, but hard real-time critical tasks.

This FPGA+NV memory would allow a TinySoftuC per Task, to/from DualPort memory, and then a larger/slower CPU like NIOS could handle from there.

This would mean it needs to be partitioned, so rather than ONE block, you can have (say) eight smaller blocks ?

To give a real example, consider a MotorController, you need quite fast PWM control, but with maybe adaptive dead-band, and overload handling, and some noise spreading, or interpolation, plus a local safe-reset. Then you have the much slower, 'what speed do you want code', operator code, etc.

-jg

That's a disclosure ? Q: Do you work for Altera, or are affiliated with Altera ? Q: Are Altera considering/analysing NV memory in FPGA ?

My guess is no, this Guy guy does not work for Altera. If he does, it's the first I've heard of him and he is violating Altera posting protocol by not clearly stating his affiliation in each posting. His email address is also not in the format of an altera address for someone with the name Guy, and besides it bounces.

We have Non-Volitile memory in our MAX II CPLD family. A Flash block is used to store the device configuration program. We also expose 8 Kb of Flash memory for use by the user -- for example, to absorb functions normally stored in off-chip serial eproms, such as a device serial number.

I cannot comment on whether or not we are considering it for future FPGA families, except to say I doubt we would conduct market research in a public forum such as this. We typically talk to all of our big customers to get feedback on family plans, and this is done under NDA.

Regards,

Paul Leventis Altera Corp.

Or drop me an email and I'll get you a gmail account.

And if you are not affiliated with Altera, be prepared for a visit from the guys in well-tailored suits. Ash Lawyers Durubultuk...

--
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

I thought I was being clear when I said not to assume I was affiliated with Altera. So to be clear about it, I am not employed by Altera nor do I have the ability to know whether they are considering or Analyzing NV memory for use in their FPGAs. Unfortunately, when creating my original post, I did not realize nor intend for the Altera email address to have been posted I simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I did not remember since it has been a long time since using Google to post (rather than other more anonymous methods). This lead to my reason for disclosure.

As an FPGA industry veteran, I am however very interested in continued market research and discussions, which I hope you will agree, can be beneficial to all FPGA users to create and provide vendors feedback.

AUSTIN-

You have made assumptions in your postings/responses with respect to security. I never mentioned the word government or any of their standards. You have assumed once again. Shame on you again? - Just kidding. Anyway, the link you provided to the xilinx website was informative

A couple of comments:

In one of my earlier posts, I did not include other options when mentioning NV memories in SRAM fpgas, I should have included battery backed SRAM, Fuse based methods for Key storage, distributed polygon approaches and likely others.

One of the most important points the Xilinx link makes which Austin neglected in his assumption that Security is no less than 100%, is the tradeoff of security with cost. While I did say that it was undetectable, I did not say it was suitable for government applications (another assumption). So, the implication in the original posting is that there would be a very low cost NV solution that would be super costly to reverse engineer (order(s) of magnitude more difficult that Flash or even Antifuse) providing a significantly lower cost solution for those non-government applications needing high security than the solutions that Altera or Xilinx currently offer.

A decent article talking about security from a practical perspective:

Also, now coming back to government, although I am not familiar with the specific published requirements (I add that due diligence to my to-do list), I do believe security has been moving target with rising requirements even for government./? So, just as Austin says that there might be ways to detect and capture the Volatile SRAM stored KEY thus enabling the cracking of governement data stream there is a level of probability and cost function involved that is the current governement requirement. I'll bet that this requirement and cost function will continue rise in time.

Austin - Why is it impossible to believe that a new NV memory technology can actually exceed this probability / cost function of detecting the stored volatile key?

As for Paul's comparison to Max II - I really do not see very many parallels to the bulk of the discusson in this thread regarding applications for the NV on chip memory. Max II does have NV memory and can potentially integrate an external solution. I am trying to emphasize that much of this thread is beyond that - especially with respect to larger data storage and other NV needs (like that of secure processor code).

More discussion?

Thanks.

the

also

public

All,

I was fooled by this posting.

Any comments I made should not in any way reflect on Altera, as the poster is obviously masquerading as someone who is.

I am mostly angry with myself that I reacted the way I did.

This is the second time I have been fooled (by a fake Altera poster)! RATS. I should know better, as Paul, and only a select few post on comp.arch.fpga from Altera.

I apologize to the newsgroup.

Aust>>That's a disclosure ?

This seems a shallow excuse, as you are STILL posting with a forged altera address in the from line.

If I was an altera lawyer, I'd already have the subpoena to google in the mail...

Oh, and just to respond to the rest of the post:

Some standards exist for a very good reason.

AES in an FPGA is ~500-1000 slices, 10 BlockRAMs, and ~10 cycles at >50 MHz in a "soft" core.

Thus, for medium-medium high security applications, using the SRAM based bitfile encryption as the security keystone costs 1 Litium cell, ~1000 slices, and 10 BlockRAMs.

Hardly a huge expense, and a significant win over nonvolatile cells. Especially since the battery itself can be used to form a nice bit of potting/intrusion detection as an additional bit of security.

--
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Nicholas - First, I have made my disclosure which unfortunately was taking 3-9 hours to post by Google which exacerbated this whole thread - sorry. I will continue under this Moniker until the end of this thread at which point I will move on to a new user name. I attempt to remain anonymous for now as have many individuals on news groups do for various reasons.

Anyways, I did not understand your point about the cost of a standard solution for AES solution. That was my whole point that potentially using a huge cost of detection NV technology would save costs in different ways: on chip NV configuration storage reducing system costs (battery, cpld, external config data).

As far as security for Key storageI did say there weren't alternatives that already exist, I was exploring the benefits of this new alternative. Then the conversation moved to other secure data storage. AES is current, before it were many other encryption standards, as time marches on, Secure becomes a non-absolute changing value. I am posing an alternative that might provide an equal or greater cost function of obtaining a stored Key than volatile/battery SRAM etc.

Thanks.

with

have

for

I

MHz