NV on-chip memory?

quick survey...

Would it be of value to provide cheap on-chip one time programmable
memory in an FPGA like Cyclone II?
Say 1-10Mbit depending on density.

It would be field or user programmable either via a programmer (very
fast) or by user logic.

It would be very secure (anti-copy) for:
 secure s/w code with on-chip processor
 secure data storage
 configuration data(s) 
 etc.

Please share your thoughts on the value (I would pay X% premium) and
the type of ways you would use it?

Thanks in advance

Atoris

Guy wrote:
> quick survey...
> 
> Would it be of value to provide cheap on-chip one time programmable
> memory in an FPGA like Cyclone II?

Yes.

> Say 1-10Mbit depending on density.
> 
> It would be field or user programmable either via a programmer (very
> fast) or by user logic.

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 ? )


> It would be very secure (anti-copy) for:
>  secure s/w code with on-chip processor
>  secure data storage
>  configuration data(s) 
>  etc.
> 
> Please share your thoughts on the value (I would pay X% premium) and
> the type of ways you would use it?

First one is easy, X = 0  :)

> 
> Thanks in advance

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, << 1MBit, which
should have minimal impact on device cost ?

-jg

>It would be very secure (anti-copy) for:
> secure s/w code with on-chip processor
> secure data storage
> configuration data(s) 

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 in thread 
From: Jim Granville (no.spam@designtools.co.nz)
Subject: Re: NV on-chip memory? 
 
  
View this article only 
Newsgroups: comp.arch.fpga
Date: 2004-09-27 21:56:28 PST 
 

Guy wrote:
> quick survey...
> 
> Would it be of value to provide cheap on-chip one time programmable
> memory in an FPGA like Cyclone II?

Yes.

> Say 1-10Mbit depending on density.
> 
> It would be field or user programmable either via a programmer (very
> fast) or by user logic.

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 ? )


> It would be very secure (anti-copy) for:
>  secure s/w code with on-chip processor
>  secure data storage
>  configuration data(s) 
>  etc.
> 
> Please share your thoughts on the value (I would pay X% premium) and
> the type of ways you would use it?

First one is easy, X = 0  :)

> 
> Thanks in advance

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, << 1MBit, which
should have minimal impact on device cost ?

-jg
Post a follow-

hmurray@suespammers.org (Hal Murray) wrote in message news:<eMWdnbmEWOAXbsXcRVn-pQ@megapath.net>...
> >It would be very secure (anti-copy) for:
> > secure s/w code with on-chip processor
> > secure data storage
> > configuration data(s) 
> 
> 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.

In article <a11322d6.0409271941.e71e499@posting.google.com>,
Guy <guys@altera.com> wrote:
>quick survey...
>
>Would it be of value to provide cheap on-chip one time programmable
>memory in an FPGA like Cyclone II?
>Say 1-10Mbit depending on density.

Would it slow down the fab or up the cost?

>It would be field or user programmable either via a programmer (very
>fast) or by user logic.
>
>It would be very secure (anti-copy) for:
> secure s/w code with on-chip processor
> secure data storage
> configuration data(s) 
> etc.

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

Guy wrote:

> 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.

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
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MR2A16A&nodeId=015424

> Answers / Comments for Jim and Hal: 
> a.  bad bits:  built in ECC would make bad bit transparant to the user

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

> 
> b.  speed = assume approximately 25ns access time

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

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

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

> 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

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

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

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

But selectively, one would hope ?

> 
> 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

  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.


> 
> 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.


<paste>
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.
 >
 > Thus the "savings" by putting it on-chip are not security, but the
 > cost savings of not needing a large external Flash PROM.

  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

HI JIM -  PLease see below.
thanks.

Jim Granville <no.spam@designtools.co.nz> wrote in message news:<d4k6d.5778$mZ2.508657@news02.tsnz.net>...
> Guy wrote:
> 
> > 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.
> 
> 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 :) ]
> 
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.

>   For an example of MRAM see
> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MR2A16A&nodeId=015424
> 
> > Answers / Comments for Jim and Hal: 
> > a.  bad bits:  built in ECC would make bad bit transparant to the user
> 
> What about a bad row/column select line - or is enough fringe test 
> memory included to test all array access lines ?
> 
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.

> > 
> > b.  speed = assume approximately 25ns access time
> 
> Any Icc projections ?
> [ROM is usually quite low power]
> 
Assume: Icc Standby = ~ 20uA
        Icc Active  = similar to on-chip/embedded sram (similar sense
amps etc)
> > 
> > c.  width = flexible, 16/32/64 bit
> 
> Why stop at 64 wide ?
> One edge on-chip memory gives is 'free width', and that can
> translate to lower power.
> 
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.

> > 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
> 
> Any values/estimates on write times / write energies / Block sizes ?
> 
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 <2mW DC per bit.  Assume min block sizes of
1 or 2Mbit.

> 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.

> > g.  external applications could read NV data too, but you obviously
> > loose security
> 
> But selectively, one would hope ?

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.
> 
> > 
> > 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
> 
>   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.
> 
> 
> > 
> > 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.
> 
> 
> <paste>
> 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.
>  >
>  > Thus the "savings" by putting it on-chip are not security, but the
>  > cost savings of not needing a large external Flash PROM.
> 
>   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

Nicholas - please see below responses.
Thanks.

nweaver@soda.csua.berkeley.edu (Nicholas Weaver) wrote in message news:<cjc7cp$qg0$1@agate.berkeley.edu>...
> In article <a11322d6.0409271941.e71e499@posting.google.com>,
> Guy <guys@altera.com> wrote:
> >quick survey...
> >
> >Would it be of value to provide cheap on-chip one time programmable
> >memory in an FPGA like Cyclone II?
> >Say 1-10Mbit depending on density.
> 
> Would it slow down the fab or up the cost?

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

> 
> >It would be field or user programmable either via a programmer (very
> >fast) or by user logic.
> >
> >It would be very secure (anti-copy) for:
> > secure s/w code with on-chip processor
> > secure data storage
> > configuration data(s) 
> > etc.
> 
> 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.

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.

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

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).

http://en.wikipedia.org/wiki/Security_through_obscurity

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 .

http://tinyurl.com/496n2

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.

Austin

Guy wrote:
> Nicholas - please see below responses.
> Thanks.
> 
> nweaver@soda.csua.berkeley.edu (Nicholas Weaver) wrote in message news:<cjc7cp$qg0$1@agate.berkeley.edu>...
> 
>>In article <a11322d6.0409271941.e71e499@posting.google.com>,
>>Guy <guys@altera.com> wrote:
>>
>>>quick survey...
>>>
>>>Would it be of value to provide cheap on-chip one time programmable
>>>memory in an FPGA like Cyclone II?
>>>Say 1-10Mbit depending on density.
>>
>>Would it slow down the fab or up the cost?
> 
> 
> See response to Jim - our goal is a standard fab process so cost would
> simply be driven by it's area.
> 
> 
>>>It would be field or user programmable either via a programmer (very
>>>fast) or by user logic.
>>>
>>>It would be very secure (anti-copy) for:
>>>secure s/w code with on-chip processor
>>>secure data storage
>>>configuration data(s) 
>>>etc.
>>
>>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.
> 
> 
> 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.
> 
> 
>>Thus the "savings" by putting it on-chip are not security, but the
>>cost savings of not needing a large external Flash PROM.
> 
> 
> 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.

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