Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 19575

Article: 19575
Subject: Re: Design security
From: krw@attglobal.net (Keith R. Williams)
Date: 1 Jan 2000 20:18:19 GMT
Links: << >>  << T >>  << A >>
On Fri, 31 Dec 1999 17:32:35, nweaver@boom.CS.Berkeley.EDU 
(Nicholas C. Weaver) wrote:

> In article <RB5b4.1138$B9.1418518@feed.centuryinter.net>,
> Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote:
> >I'm looking at an FPGA for project I'm working on and am concerned about
> >security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for
> >me.
> >
> >I'm looking at Altera and Xilinx.
> >
> >It appears that most FPGA's are programmed with a serial eeprom. I'm
> >concerned about the security the data in the eeprom. What keeps someone from
> >simply copying your eeprom to duplicate your FPGA's programming?
> 
> 	Nothing.  
> 
> 	It really depends on how security paranoid you are.  If you
> want to eliminate unsophisticated copying and all but the most
> sophisticated copying (taking apart the chip), use an eeprom based
> programmable device.
> 
> 	If you REALLY want protection, use an sram based FPGA with a
> continual battery backup, so the device is always on.  Any disturbance
> to the power will erase the device.

Depending on the level of security you're after, even this may 
not be "secure" unless you can secure the physical environment 
that it will be in. I did crypto key storage/management design 
(not classified) a few years ago. One of the scenarios we dealt 
with was an X-Ray attack on the key storage SRAM. SRAMs tend to 
harden in the state they're in when exposed to X-Rays. That is, 
they tend to prefer that state for subsequent power-on cycles. It
sounds like a rather obscure attack (no I didn't test it ;-), but
don't assume a powered SRAM is safe from all attacks.  

> >Maybe this is a stupid question but I'm still learning about FPGA's. Since I
> >will have some encryption / decryption functions in the FPGA, this is a big
> >concern for me. What do you need to do to protect your design when using
> >FPGA's ?
> 
> 	I really wouldn't be paranoid about the functions.  A good
> security system's security rests in the key/secret DATA, not in the
> algorithm.  So I'd be paranoid about the data.  This would suggest an
> always on device with battery backup.

I'm in the camp that says (at least for commercial use) a known 
algorithm is better than an unknown one. The better it's known 
the more likely that someone has at least spent time trying to 
shoot it full of holes. However, a powered circuit isn't perfect 
- nothing is. Just like locking your house, the point is to 
expend enough effort on the defense to make the offender look 
elsewhere. This effort varies depending on what's at risk.

----
  Keith

Article: 19576
Subject: Re: Design security
From: "John Cain" <jjcain@goodnet.com>
Date: Sat, 1 Jan 2000 12:38:23 -0800
Links: << >>  << T >>  << A >>
Larry,

You concern is real. I do embedded design for a wide range of customers.
I use a variety of FPGA & EPLD devices and I have yet to get an SRAM device
into production.

Once the "SUITS" figure out that the SRAM device offers no IP security,
management directs a different solution requiring either a hard version for
the SRAM part (such as offered by Xilinx or Altera/etc) or an ISP version
with a security bit.  For your application you should check if your customer
will accept an SRAM based FPGA as part of your design. For example, SRAM
parts are not allowed in some military or high reliability applications.

An ISP solution with a security bit is available from many vendors and
certainly raises the bar of IP
security in an FPGA, but is not totally secure.

For example, one of my clients had a problem with an HR-1 eNGINEER who liked
the design so well that the one day he took it home and left nothing, but,
the secured ISP test prototype.  Contacting the mfg and 1st world resources
were of no help; everyone claimed the design was secure and the company was
screwed.

In the third world, it cost a few thousand dollars and a couple of weeks to
reverse the ISP parts.


John Cain, Power Processing, Inc.
jjcain@goodnet.com, 602 549 6604V, 480 759 4675V/F



Article: 19577
Subject: Re: Design security
From: "Larry Edington" <larryeSpam.Me.Not@centuryinter.net>
Date: Sat, 1 Jan 2000 20:19:08 -0600
Links: << >>  << T >>  << A >>
So it looks like I do understand after all.

What I still don't understand is why Altera and Xilinx, who I think are the
top 2 vendors of these parts, don't have ISP FPGA's with security bits. Or
maybe they do and I just missed it. Next week I'll try to run down an Altera
and Xilinx FE for a discussion of my needs.

Antifuse won't work for me nor will SRAM battery backup methods. I need in
field reprogrammability and I don't want a dead device due to dead
batteries.

It's not a military device and doesn't have to be super spook secure. I just
wanted to make it hard for casual copying. I know it can be reverse
engineered just like a 20L8 PLD can. But at least with a 20L8 you can't just
pop it in a programmer and copy it if you set the security bit. Yea, you can
pay to have it copied 'overseas' but at least you gotta pay.

Thanks for all the help.

Larry E.




John Cain <jjcain@goodnet.com> wrote in message
news:vLsb4.499$197.49682@news.goodnet.com...
> Larry,
>
> You concern is real. I do embedded design for a wide range of customers.
> I use a variety of FPGA & EPLD devices and I have yet to get an SRAM
device
> into production.
>
> Once the "SUITS" figure out that the SRAM device offers no IP security,
> management directs a different solution requiring either a hard version
for
> the SRAM part (such as offered by Xilinx or Altera/etc) or an ISP version
> with a security bit.  For your application you should check if your
customer
> will accept an SRAM based FPGA as part of your design. For example, SRAM
> parts are not allowed in some military or high reliability applications.
>
> An ISP solution with a security bit is available from many vendors and
> certainly raises the bar of IP
> security in an FPGA, but is not totally secure.
>
> For example, one of my clients had a problem with an HR-1 eNGINEER who
liked
> the design so well that the one day he took it home and left nothing, but,
> the secured ISP test prototype.  Contacting the mfg and 1st world
resources
> were of no help; everyone claimed the design was secure and the company
was
> screwed.
>
> In the third world, it cost a few thousand dollars and a couple of weeks
to
> reverse the ISP parts.
>
>
> John Cain, Power Processing, Inc.
> jjcain@goodnet.com, 602 549 6604V, 480 759 4675V/F
>
>
>


Article: 19578
Subject: Re: Design security
From: edick@hotmail.com (Richard Erlacher)
Date: Sun, 02 Jan 2000 03:47:13 GMT
Links: << >>  << T >>  << A >>
On Sat, 1 Jan 2000 09:28:36 -0600, "Larry Edington"
<larryeSpam.Me.Not@centuryinter.net> wrote:

>I'm not concerned about a hacker obtaining the contents of the 'logic' in
>the FPGA. That I know would be very difficult and those with the resources
>to do so would spend those resources designing a new device from scratch.
>
>My biggest concern is simple copying.
>
>If an FPGA is programmed with a configuration eeprom, then won't simply
>copying that configuration eeprom allow you to put a blank XYZ FPGA on a
>board with your copy of the eeprom, and thus duplicate my programming on my
>board? Or am I not understanding the basics of FPGA programming?
>
>I realize a device that doesn't use a configuration eeprom that is
>programmed strictly internally with a security bit set is sufficient for my
>security needs. Just like an old PLD and it's programming fuse. But, I'm
>still unclear what that external eeprom devices opens up to a hacker.
>
>I did notice an app note on the Xilinx page where a security bit can be set
>on a config eeprom that prevents reading from the jtag port. If a device
>programmer
>couldn't read it as well then this would be sufficient for my design.
>
>Thanks for all the replys so far!
>
>Larry E.
>
>
>Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote in message
>news:RB5b4.1138$B9.1418518@feed.centuryinter.net...
>> I'm looking at an FPGA for project I'm working on and am concerned about
>> security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick
>for
>> me.
>>
>> I'm looking at Altera and Xilinx.
>>
>> It appears that most FPGA's are programmed with a serial eeprom. I'm
>> concerned about the security the data in the eeprom. What keeps someone
>from
>> simply copying your eeprom to duplicate your FPGA's programming?
>>
>> Maybe this is a stupid question but I'm still learning about FPGA's. Since
>I
>> will have some encryption / decryption functions in the FPGA, this is a
>big
>> concern for me. What do you need to do to protect your design when using
>> FPGA's ?
>>
>> thanks,
>> Larry E.
>> Remove Spam_me_not to reply via email.
>>
============================================================
If you have IP that's worth anything and particularly if you're using
a BIG FPGA and little else on your circuit board (common, these days)
and then having your first 100K boards made in Taiwan or Korea, you'd
best consider that within a week of when production of your boards
begins, someone will be collecting the junk boards from the PCB house.
Next, they'll find your product and attach a logic analyzer to the
data feed to your FPGA from the config rom, and within minutes have a
copy of your config rom.  Now they faithfully copy your documentation,
then the cover of your boxes.  Now they can build the complete
product.  

Next, they sell the defective boards with counterfeit boxes and
documents to unsuspecting distributors (with a blind eye turned to
these risks!) and they then sell the boards to your potential
customers.  They, in turn, find out your product doesn't work, and you
end up with twice as many RMA's out there as you've sold product.  You
replace the counterfeits with good product, and, soon, go out of
business having lost your shirt, your house, your kid's bicycle, etc.

Dick
>

Article: 19579
Subject: Re: Design security
From: "Larry Edington" <larryeSpam.Me.Not@centuryinter.net>
Date: Sat, 1 Jan 2000 23:58:00 -0600
Links: << >>  << T >>  << A >>
> If you have IP that's worth anything and particularly if you're using
> a BIG FPGA and little else on your circuit board (common, these days)

My FPGA will just replace a few other chips and contain some encryption
routines.

> and then having your first 100K boards made in Taiwan or Korea, you'd
> best consider that within a week of when production of your boards
> begins, someone will be collecting the junk boards from the PCB house.

Which is why I'll not be going to Taiwan for the first 100K. ( I hope
anyway )

> Next, they sell the defective boards with counterfeit boxes and
> documents to unsuspecting distributors

Since this is a corporate device, and won't be going to distributors for
resale, but direct to the corporate end users, I'm not worried about that
scenario.

Now if I had done the latest and greatest kids toy, then yea, that'll
probably
all happen. IP theft is a BIG problem. That's why I just can't understand
why the
FPGA vendors haven't done something more about it.

later,
Larry E.



Article: 19580
Subject: Re: Design security
From: murray@pa.dec.com (Hal Murray)
Date: 2 Jan 2000 09:20:58 GMT
Links: << >>  << T >>  << A >>

> What I still don't understand is why Altera and Xilinx, who I think are the
> top 2 vendors of these parts, don't have ISP FPGA's with security bits. Or
> maybe they do and I just missed it. Next week I'll try to run down an Altera
> and Xilinx FE for a discussion of my needs.

I think you may have missed a key point.  There is nothing significantly
different between "ISP" and loading via an EPROM.  The configuration
bits are on the pins where a logic anlayzer can grab them.

As far as I can tell, there isn't any easy answer to this problem.
-- 
These are my opinions, not necessarily my employers.
Article: 19581
Subject: Re: hobbyist friendly pld?
From: edick@hotmail.com (Richard Erlacher)
Date: Sun, 02 Jan 2000 15:07:13 GMT
Links: << >>  << T >>  << A >>
Actually, the software from VANTIS, now owned by LATTICE, is, indeed,
free.  Unfortunately, most of the smaller devices, and this applies
not only to Lattice/Vantis, but to most others as well,  require a
relatively complex programmer which implements the programming
algorithims that the component manufacturers won't give you and the
larger parts are so pin-rich that you have little choice but to
program them in-situ, which is inconvenient, since you can't socket
them without spending more than what a programmer for the small
devices would cost, and such large-pin-count packages are not very
friendly to the hobbyist, particularly since you have to build them
into a PCB.

Dick

On Tue, 07 Dec 1999 12:57:09 +0000, Tim Forcer
<tmf@ecs.soton.ac.uk.nojunk> wrote:

>Dan Rymarz wrote:
>> 
>> Hello all,
>> 
>> I am looking for a programmable logic technology I can use that
>> also has a free+permanant (not 30 day trial) compiler available,
>> that uses JTAG or similar few-wire (4 for jtag etc.) programming
>> mode.  I don't need a large gate count.  ...
>
>Have a look at Lattice.  They do an isp version of the trusty 22V10. 
>The starter pack software to handle this is based on ABEL - again a
>trusty "standard".  Software isn't free, but the deal on the starter
>pack is normally pretty good, and includes some devices and a download
>cable.  Info at
><http://www.latticesemi.com/products/destools/ispstarter.html>.  Lattice
>also now incorporate Vantis (was AMD not that long ago), and there's a
>similar starter kit for Vantis MACH parts
><http://www.latticesemi.com/products/destools/mstarter.html>.
>
>Best deals of all, in my experience, come when you go along to a
>company's introductory "seminar" presentation.  You pay for the day or
>half-day, but get a free intro kit, plus manuals, plus several sessions
>which are half-way between sales talk and "how-to" instruction.  There's
>a fair amount of opportunity for some hands-on evaluation of the
>software.  You sometimes get vouchers to use should you decide to buy
>more of the stuff or to upgrade from starter kit to a higher level. 
>Look up the main distributors of Lattice, and try to find out when the
>next "roadshow" comes somewhere near you.
>
>Usual warning I give to anyone getting into isp devices: take great care
>with your power supply.  ispICs incorporate an on-chip voltage
>multiplier.  If this sees a Vcc spike outside the absolute maximum
>rating, it will turn the whole chip into an expensive multi-terminal one
>Ohm resistor.  Check the Vcc for spikes BEFORE fitting the isp stuff -
>don't rely on the fact that you've used this for years with all manner
>of 74 series and stick-it-in-the-programmer PLDs - those devices will
>take up to 100% overload spikes and (most of the time) not even go into
>a reset or malfunction mode, certainly won't suicide.
>
>-- 
>Tim Forcer               tmf@ecs.soton.ac.uk
>The University of Southampton, UK
>
>The University is not responsible for my opinions

Article: 19582
Subject: Re: Design security
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sun, 2 Jan 2000 08:48:45 -0800
Links: << >>  << T >>  << A >>
Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote in message
news:AAyb4.1186$B9.1484255@feed.centuryinter.net...
> Antifuse won't work for me nor will SRAM battery backup methods. I need in
> field reprogrammability and I don't want a dead device due to dead
> batteries.

So if you're going to be re-programming the devices in the field, what
prevents anyone from capturing your ISP bitstream at that point?

> It's not a military device and doesn't have to be super spook secure. I
just
> wanted to make it hard for casual copying. I know it can be reverse
> engineered just like a 20L8 PLD can. But at least with a 20L8 you can't
just
> pop it in a programmer and copy it if you set the security bit. Yea, you
can
> pay to have it copied 'overseas' but at least you gotta pay.

I think there's a significant difference between simply being able to copy a
device and being able to reverse engineer it and obtain its IP.  In the
former case, it's seems to me that it's much easier to demonstrate that some
law has been broken, and take the appropriate legal action.  In the later
case, if you have some system on a chip that has some nice PCI core, say an
MPEG encoder/decoder, etc., and "they" got ahold of that and start using it
in their own designs, you're probably completely out of luck trying to prove
that any law was broken -- unless perhaps you can claim patent infringement,
somehow.

Can anyone name some commercial product that was counterfeited where the
counterfeit products actually started eating (significantly) into the bottom
line of the company that engineered the device?  I've often felt that the IP
piracy threat has been a little overblown at times, but I work for a
relatively small company where the equipment we make is so specialized (and
expensive) that it's pretty unconceivable that anyone would run off and
attempt to replicate it -- hence I may have a warped perspective on this.

---Joel Kolstad



Article: 19583
Subject: Re: Design security
From: "John Cain" <jjcain@goodnet.com>
Date: Sun, 2 Jan 2000 13:44:13 -0800
Links: << >>  << T >>  << A >>
Larry,

You are right. Better forms of FPGA protection are necessary.
Currently, the only reasonable cost secured protected devices
are UPs from Philips & Dallas.

SRAM FPGAs could easily be made secure by the addition of a fixed DES
Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed.
Now you can OTP the FPGA device key & encript the external configuration
eeprom and everything remains protected.

A DES cell would not be that big with current FPGAs based on <0.25u CMOS
processes. Better FPGA protection is definitely necessary as digital
embedded
products become a single chip system based on an FPGA.

John Cain, Power Processing, Inc., Phoenix, AZ
jjcain@goodnet.com








Article: 19584
Subject: Re: Design security
From: "Larry Edington" <larryeSpam.Me.Not@centuryinter.net>
Date: Sun, 2 Jan 2000 17:09:45 -0600
Links: << >>  << T >>  << A >>
> So if you're going to be re-programming the devices in the field, what
> prevents anyone from capturing your ISP bitstream at that point?

More work to figure it out than to design it themselves from scratch. Plus
several 'traps' are in the device that will render it inoperable. If a
particular
company keeps coming up with an unusual number of tampered units, then
we know we have a problem.


> Can anyone name some commercial product that was counterfeited where the
> counterfeit products actually started eating (significantly) into the
bottom
> line of the company that engineered the device?

IBM PC for one.

later,
Larry E.



Article: 19585
Subject: Re: Design security
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sun, 2 Jan 2000 16:59:27 -0800
Links: << >>  << T >>  << A >>
Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote in message
news:jVQb4.1213$B9.1529941@feed.centuryinter.net...
> > So if you're going to be re-programming the devices in the field, what
> > prevents anyone from capturing your ISP bitstream at that point?
>
> More work to figure it out than to design it themselves from scratch.

I'm not following how... usually the in-circuit programming signals are very
well defined by the device manufacturer, and turning them back into a
bitstream seems very straightforward to me.

> Plus
> several 'traps' are in the device that will render it inoperable.

Traps based on trying to detect reverse engineering, huh?  Interesting.

I have heard of approaches where there's a counter inside of a device that
keeps track of how many, say, bus reads have occurred since the last access
to a particular register.  Every tenth thousandth read, or thereabouts, the
device purposely "breaks" the standard bus protocol (e.g., runs off and
flips a few of the data bits for the returned result); the software talking
to the device has to be aware of how the break occurs and "correct" the
"break."  Somebody who sits down and attempts to reverse-engineer the design
will hook the thing up to a logic analyzer and (presumably) never notice the
broken access cycles, so their copy won't function correctly if they simply
copy the original software as well.

> > Can anyone name some commercial product that was counterfeited where the
> > counterfeit products actually started eating (significantly) into the
> bottom
> > line of the company that engineered the device?
>
> IBM PC for one.

I'm not so sure that's a good example.  Arguably the original IBM PC didn't
really contain much IP; it was not particularly different than an Intel
reference design.  The valuable thing about the PC, I would imagine, was in
DOS 1.0 -- and that was already legally protected.

---Joel Kolstad



Article: 19586
Subject: Re: Using internal RAM in Altera Flex 10KE
From: andy_ash@my-deja.com
Date: Mon, 03 Jan 2000 04:12:13 GMT
Links: << >>  << T >>  << A >>
I only have the old 8.2 version of max here so I can't garantee that
the paths will be the same but if you look in your maxplus2 directory
you should find the "\vhdl93\altera\" directory.

Inside this directory is the file maxplus2.vhd which is a vhdl package.
The package contains common 74 series functions. You should be able to
find components to do your business there.

I only have the old cycle shared single port memory functions in mine
but this is because the software I have was released before the part
you are using.

You should find VHDL components for all of the device specific
functions in there.

Merry new millennium.

Andy.


In article <84hclo$ob8$1@clematis.singnet.com.sg>,
  "MK Yap" <mkyap@ieee.org> wrote:
> Hi !
>
> I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently
using
> Altera's Maxplus2 9.3.  From the specs, it has a total RAM of 49152
bits.
>
> My question is: how can i make use of the RAM? whenever i define an
array,
> variable or signal in VHDL , I realize that the RAM is not being
used.  What
> should I do to force it to use the RAM?
>
> Thank you!
>
> MKYap
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19587
Subject: Re: PCI slot 3.3V pins.
From: Burn@D.man (Free Spirit)
Date: Mon, 03 Jan 2000 06:56:35 GMT
Links: << >>  << T >>  << A >>
Yep, I got bit by this too.. Gigabyte provides 3.5V to the 3.3V PCI power pins,
this really messes with MAX7000A's , Soyo brings 3.3V ATX power to the PCI.
I have a board that uses the 5V supply to run a 15W cpu, there's not enough
margin left to run all the 3.3V logic, CPU I/O, and DIMMs. Rev2 will get
its 3.3V Regulated From 5V using an extra floppy power connector, most ATX
systems have 2. Still using the PCI 5V to get the 2.0 CPU CoreV.

Am I asking for ground loop problems?


On 31 Dec 1999 11:08:34 +0100, Magnus Homann <d0asta@mis.dtek.chalmers.se>
wrote:

>"Austin Franklin" <austin@d33arkroom.com> writes:
>
>> Magnus Homann <d0asta@licia.dtek.chalmers.se> wrote in article
>> <lt7lhwpzna.fsf@licia.dtek.chalmers.se>...
>> > "Austin Franklin" <austin@darkroo99m.com> writes:
>> > 
>> > > As you said, per the PCI spec (contrary to the original posters
>> ascertain)
>> > > in a 5V signaling environment, the system board manufacturer is not
>> > > required to provide 3.3V to the connectors.
>> > 
>> > They are required to put in 3.3V in PCI 2.2. The old PCI 2.1 didn't
>> > require the 3.3V power rail in a 5V environment, though.
>> > 
>> > [...]
>> > 
>> > > As was stated, if you want to make a 33MHz PCI card, and you require
>> 3.3V
>> > > on your board, you have to provide the regulator on board and make 3.3V
>> > > from the +12 or the +5...
>> > 
>> > Unless the motherboard is PCI 2.2 compliant. I think making the 3.3V
>> > optional was a big mistake.
>> 
>> If I was making a PCI card, I would not count on the 3.3V being there,
>> since there are hundreds of MILLIONS of system boards without the 3.3V
>> there....so if you want to sell cards, which is what I believe most
>> manufacturers goal is, use an on board regulator....
>
>Sure, I agree. And that is the problem with making the 3.3V
>optional. You can't gurantee that there is 3.3V, so you have to make
>your own, even if there is 3.3V available.qq
>
>As a side note, a board manufacturer, who shall remain nameless, made
>the 3.3V optional by using a regular jumper to connect the 3.3V from
>the motherboard power plane to the slot. That had the effect that the
>voltage went down to 3.15V at the dauhgter board. Which happens to be
>the lower limit for certain devices...
>
>Homann

Article: 19588
Subject: Re: Design security
From: Ray Andraka <randraka@ids.net>
Date: Mon, 03 Jan 2000 09:47:22 -0500
Links: << >>  << T >>  << A >>
The problem with putting an OTP key in the device, is that the non-volatile
cells can't be fabricated without additional process steps.  The FPGA
process is essentially the same as DRAM, which lets it be done with bleeding
edge process.  Put PROM cells on there, and you lose the speed.

John Cain wrote:

> Larry,
>
> You are right. Better forms of FPGA protection are necessary.
> Currently, the only reasonable cost secured protected devices
> are UPs from Philips & Dallas.
>
> SRAM FPGAs could easily be made secure by the addition of a fixed DES
> Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed.
> Now you can OTP the FPGA device key & encript the external configuration
> eeprom and everything remains protected.
>
> A DES cell would not be that big with current FPGAs based on <0.25u CMOS
> processes. Better FPGA protection is definitely necessary as digital
> embedded
> products become a single chip system based on an FPGA.
>
> John Cain, Power Processing, Inc., Phoenix, AZ
> jjcain@goodnet.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19589
Subject: Re: Virtex Config Help
From: Ray Andraka <randraka@ids.net>
Date: Mon, 03 Jan 2000 09:57:12 -0500
Links: << >>  << T >>  << A >>
Might help if you posted your small test design.  Are you using the CLKDLLs
for the virtex design?  ALso, have your pins been assigned correctly?

As a first step, you might open the design under the FPGA editor (formerly
epic) and browse around to make sure it is what you though it was as far as
clocks, resets, and io locations.

Timothy Miller wrote:

> Thanks for the response, but I'm afraid that this isn't the problem
> either because we are doing exactly what you suggested that we do.
>
> We have also tried configuring it in slave-serial mode (yes, m2..m0 are
> set correctly) and it also says the download was successful.
>
> I have even tried running this with and without I/O parameters set
> (lvttl, 2ma, 4ma).  Only once did it actually output something.
>
> Ever since then it has been dead as a doornail.  A small test design was
> downloaded into a XC4005E and functioned properly.  When it was
> retargeted for the XCV1000 we did not see any output.
>
> If you can help us with this, we would greatly appreciate it.  Thanks.
>
> In article <84e47m$h0s$1@bgtnsc01.worldnet.att.net>,
>   "peter dudley" <padudle@worldnet.att.net> wrote:
> > Timothy
> >
> > The JTAG configuration interface is a bit misleading. It will say it
> > configured just fine even though it has not gone through startup.
> Nicolas
> > helped me with this one in an earlier post if you have the same
> problem that
> > I had.
> >
> > You need to go into the design->options menu. Click on edit options
> next to
> > configuration and select the startup tab. For the startup clock source
> > select JTAG.
> >
> > Hope that's it.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19590
Subject: Re: IRDY/TRDY Dedicated or Special Pin Name
From: Ray Andraka <randraka@ids.net>
Date: Mon, 03 Jan 2000 10:03:33 -0500
Links: << >>  << T >>  << A >>
These pins have a little extra logic associated with them for driving the clock
enables on the output registers in the IOBs along the edge they are on.  You can
see the logic block and it's connections if you look at the middle of the edge
in the FPGA editor.  So what makes these pins special is that they provide a
very fast clock enable to the outputs.  Xilinx's position is that this function
is unsupported except for use with their PCI interface macro.

peter dudley wrote:

> Hello All
>
> I was looking at my .pad report file for a new Virtex design and I noticed
> something new.
>
> Under the "Dedicated or Special Pin Name" section, pins called IRDY and TRDY
> are each listed twice. On the TQ144 package they are on pins 53 and 56 but
> then they are repeated on pins 130 and 127.
>
> IRDY and TRDY are signal names in the PCI standard. Are these pins special
> in any way on the Virtex chip? Do they have special drive strengths to meet
> PCI requirements?
>
> Any insight would be appreciated.
>
>     Pete
>
> --
> Pete Dudley
>
> Arroyo Grande Systems Incorporated

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19591
Subject: Re: FG and H function in Xilinx FPGA
From: Ray Andraka <randraka@ids.net>
Date: Mon, 03 Jan 2000 10:07:01 -0500
Links: << >>  << T >>  << A >>
I'm not sure I understand your question.  The FG and H function generators
are a part of the CLB.  Each 4K CLB contains two FG generators (4 input
look-up tables) and one H generator (3 input LUT).  Read the data sheet to
understand the structure.  You really should have at least a basic
understanding of the structure before doing a design in the part.


wannarat wrote:

> Dear All
>     after I synthesis the design I found that FG and H function in FPGA
> are very big.
> They used about nearly 300 % of the resource while used CLB only 30%.
> How can reduce or optimize or .. suggest me?
>
> Best REgard
> Wannarat
>
> --
> Wannarat Suntiamorntut
> Computer System Design Laboratory (CSDL)
> Computer Engineering Department
> Prince of Songkla University, Hatyai, Songkla 90112 Thailand
> Tel. 66-074-212895  ext.311  Fax. 66-074-212895
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19592
Subject: Re: Design security
From: eml@riverside-machines.com.NOSPAM
Date: Mon, 03 Jan 2000 15:18:47 GMT
Links: << >>  << T >>  << A >>
On Sun, 2 Jan 2000 13:44:13 -0800, "John Cain" <jjcain@goodnet.com>
wrote:

>Larry,
>
>You are right. Better forms of FPGA protection are necessary.
>Currently, the only reasonable cost secured protected devices
>are UPs from Philips & Dallas.
>
>SRAM FPGAs could easily be made secure by the addition of a fixed DES
>Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed.
>Now you can OTP the FPGA device key & encript the external configuration
>eeprom and everything remains protected.
>
>A DES cell would not be that big with current FPGAs based on <0.25u CMOS
>processes. Better FPGA protection is definitely necessary as digital
>embedded
>products become a single chip system based on an FPGA.

56-bit keys aren't much use these days. if you have secure
information, you should probably be encrypting with 1000-bit keys,
which should give security for the next few years. A 512-bit key was
recently cracked (RSA-155) - IIRC, this took about 35 CPU years,
including time on a cray, but this will probably become commonplace
over the next couple of years.

i don't think putting encryption hardware on the silicon is necessary.
at the minimum, all the silicon needs is 1024 bits of 'secure' OTP
memory, and some mechanism to drive the configuration process from an
existing configuration (ie. divide the chip into 2 separate
configuration areas, and drive the JTAG chain internally). you could
then load your uncoded decryption engine from PROM, and use your
unique OTP'd key to decode the rest of the bitstream, and program the
remainder of the device.

evan

Article: 19593
Subject: Re: An online division unit with constant divisor
From: jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 3 Jan 2000 16:03:59 GMT
Links: << >>  << T >>  << A >>
From article <84da08$nne$1@news.qub.ac.uk>, by "J.R." <j_robby@hotmail.com>:
> 
> Does anybody know where I can find an algorithm for Radix-2 online division
> (Radix-2  serial Signed Digit arithmetic) with a constant divisor.

See http://www.cs.uiowa.edu/bcd/divide.html
for a tutorial on division by reciprocal multiplication.  The
tutorial uses the example of division by 10 to 16 bits precision,
but the method generalizes to other divisors.  Here is the solution
that the tutorial gives at the end.  This code has been exhaustively
tested:

        unsigned int A;
        unsigned int Q; /* the quotient */

        Q = ((A >> 2) + A) >> 1; /* Q = A*0.101 */
        Q = ((Q     ) + A) >> 1; /* Q = A*0.1101 */
        Q = ((Q >> 2) + A) >> 1; /* Q = A*0.1001101 */
        Q = ((Q     ) + A) >> 1; /* Q = A*0.11001101 */
        Q = ((Q >> 2) + A) >> 1; /* Q = A*0.10011001101 */
        Q = ((Q     ) + A) >> 1; /* Q = A*0.110011001101 */
        Q = ((Q >> 2) + A) >> 1; /* Q = A*0.100110011001101 */
        Q = ((Q     ) + A) >> 4; /* Q = A*0.0001100110011001101 */
        /* Q = A/10 exactly */

				Doug Jones
				jones@cs.uiowa.edu
Article: 19594
Subject: Re: Using internal RAM in Altera Flex 10KE
From: David Kessner <davidk@free-ip.com>
Date: Mon, 03 Jan 2000 09:38:17 -0700
Links: << >>  << T >>  << A >>


MK Yap wrote:
> I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently
> using Altera's Maxplus2 9.3.  From the specs, it has a total RAM 
> of 49152 bits.
> 
> My question is: how can i make use of the RAM? whenever i define
> an array, variable or signal in VHDL , I realize that the RAM is
> not being used.  What should I do to force it to use the RAM?

There are three options, two of which have already been
mentioned (instantiate LPM library components, and their
macro generator).  But there is a third choice...

The Free-IP Project has the Free-RAM core (http://www.free-ip.com).
This core is a portable RAM library for use with Altera and Xilinx
FPGA's as well as simulators such as ModelSIM.  

The way Altera did RAM in Max II+, it is fairly easy to use.
Using the Free-RAM core is about as easy.  The difference
is that the Free-RAM core is portable and gives you many more
options when finalizing your design since you can then
easily try your design in different FPGA's without significant
work.

Hope that helps!

David Kessner
davidk@free-ip.com
Article: 19595
Subject: Re: Design security
From: Steve Dewey <steve@s-dewey123.demon.co.uk>
Date: Mon, 3 Jan 2000 20:30:07 +0000
Links: << >>  << T >>  << A >>
In article <RB5b4.1138$B9.1418518@feed.centuryinter.net>, Larry Edington
<larryeSpam.Me.Not@centuryinter.net> writes
>I'm looking at an FPGA for project I'm working on and am concerned about
>security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for
>me.
>
>I'm looking at Altera and Xilinx.
>
>It appears that most FPGA's are programmed with a serial eeprom. I'm
>concerned about the security the data in the eeprom. What keeps someone from
>simply copying your eeprom to duplicate your FPGA's programming?
>

One option that does not appear to have been suggested is to prototype
using Altera chips and then go to Clear Logic's identical laser
programmed parts for production. Best check which Altera parts Clear
Logic support, though.
-- 
Steve Dewey
Article: 19596
Subject: Re: VGA controller in FPGA
From: Steve Dewey <steve@s-dewey123.demon.co.uk>
Date: Mon, 3 Jan 2000 20:32:13 +0000
Links: << >>  << T >>  << A >>
In article <r34a4.968$B9.1198772@feed.centuryinter.net>, Larry Edington
<larryeSpam.Me.Not@centuryinter.net> writes
>Would anyone know of a VGA controller I could license for a FPGA? Nothing
>fancy needed. In fact,
>640 x 480 would be fine. DAC of course would be external. Hoping to use
>Altera Flex.
>
>thanks,
>Larry E.
>
>
>
If I Recall Correctly, There is a VGA timing generator in AHDL at
www.freecore.com. Might get you started.
-- 
Steve Dewey
Article: 19597
Subject: Re: Design security
From: murray@pa.dec.com (Hal Murray)
Date: 3 Jan 2000 21:24:34 GMT
Links: << >>  << T >>  << A >>

In article <3870B679.D84288FD@ids.net>,
 Ray Andraka <randraka@ids.net> writes:
> The problem with putting an OTP key in the device, is that the non-volatile
> cells can't be fabricated without additional process steps.  The FPGA
> process is essentially the same as DRAM, which lets it be done with bleeding
> edge process.  Put PROM cells on there, and you lose the speed.

I'm not a silicon guru.  This case is different from a normal
PROM in that we don't need a lot of bits.

Is there any fabrication method that can build non-volatile storage
without sacrificing speed/cost for the rest of the chip if I don't
care much about how much space each bit takes up?

I think a write-once corner would be good enough.

-- 
These are my opinions, not necessarily my employers.
Article: 19598
Subject: Re: Design security
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Mon, 03 Jan 2000 23:28:06 GMT
Links: << >>  << T >>  << A >>
On Mon, 03 Jan 2000 15:18:47 GMT, eml@riverside-machines.com.NOSPAM
wrote:

>56-bit keys aren't much use these days. if you have secure
>information, you should probably be encrypting with 1000-bit keys,
>which should give security for the next few years. A 512-bit key was
>recently cracked (RSA-155) - IIRC, this took about 35 CPU years,
>including time on a cray, but this will probably become commonplace
>over the next couple of years.

Depends on the encryption algorithm used. RSA relies on factoring
prime numbers and so is nowhere near so secure for the same key
length. It's also "quite" laborious in hardware or software because of
the modulo arithmetic. Your configuration time would be rather
extended, to say the least.

You could safely use a symmetrical key cryptosystem as programming the
"key" into the FPGA is a secure transmission in the factory. Hence no
need for public-key crypto. A 56-bit key in DES would be quite strong,
and while a 56-bit DES key has been recovered in around 2 hours, you
have to remember that that was a "known plain text" attack (as the RSA
ones have been as well, AFAIK). While the headers of a bit-stream
would be in the clear (no valuable info), the actual encrypted payload
of programming bits would not be known ASCII text or regular known
patterns particularly, and therefore would not be prone to more common
crypto attempts such as known header or dictionary attacks. I wouldn't
use ECB mode of DES though as it leaves plain-text repeat-patterns
visible (just in case the bitstream is filled with a long string of
zero's or 1's which they may well be).

I suspect that some of the reasons the vendors have not put crypto
into FPGA's are (in no particular order):

1 - Performance and cost due to additional mask layers on the process
2 - Government restrictions regarding crypto import/export
3 - Lack of "real" user interest i.e. people who will actually "Pay"
for the feature in a standard product.
4 - Lack of alternative product. i.e. none of the big 3 offer
reprogrammable, secure devices using encryption. If one did, I suspect
all would.

>i don't think putting encryption hardware on the silicon is necessary.
>at the minimum, all the silicon needs is 1024 bits of 'secure' OTP
>memory, and some mechanism to drive the configuration process from an
>existing configuration (ie. divide the chip into 2 separate
>configuration areas, and drive the JTAG chain internally). you could
>then load your uncoded decryption engine from PROM, and use your
>unique OTP'd key to decode the rest of the bitstream, and program the
>remainder of the device.

hmmm, sounds damn messy to me, and brings this nasty partial
configuration stuff into the equation.

In an ideal world, a vendor would offer a core with triple-DES crypto
by default where the delivered (unprogrammed) state was a key of
all-zero. Devices would be OTP (with no key recovery of course) and
the bit-stream generator would have a tick-box and key value selector
for the user to generate an encrypted bitstream to throw into the
regular configuration mechanism.

Sounds like a feasible idea doesn't it?

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 19599
Subject: Re: Design security
From: "John Cain" <jjcain@goodnet.com>
Date: Mon, 3 Jan 2000 17:26:42 -0800
Links: << >>  << T >>  << A >>
Ray,

Your right about the added mask & process steps. However, they do not
represent a serious cost
issue. CMOS masks are $1-2k per layer for >0.5um, and several times that for
<0.5um.
Worst case thats $15-30k as part of the large custom cmos chip that
implements the FPGA device.

I was thinking of an added 56bit onchip eeprom for the DES key as part of
the FPGA device.  This leaves the SRAM CMOS device as is. Many <0.5um
processes offer an eeprom or eprom option. It bumps the total chip cost
about 10%.

John Cain, Power Processing, Inc., Phoenix, AZ
 jjcain@goodnet.com

>Ray Andraka wrote in message <3870B679.D84288FD@ids.net>...
>The problem with putting an OTP key in the device, is that the non-volatile
>cells can't be fabricated without additional process steps.  The FPGA
>process is essentially the same as DRAM, which lets it be done with
bleeding
>edge process.  Put PROM cells on there, and you lose the speed.

>-Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email randraka@ids.net
>http://users.ids.net/~randraka





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search