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 19550

Article: 19550
Subject: XC9500 0,5u Mask: Errors?
From: Genio Kronauer <g.kronauer@kronauer-digital.de>
Date: Thu, 30 Dec 1999 11:35:10 +0100
Links: << >>  << T >>  << A >>
Recently Xilinx has changed process for XC900 series from 0.6u to 0.5u,
see also http://www.xilinx.com/partinfo/notify/pcn9803.htm .
Since that, some 30% of chips of a certain design work, other designs
work
on 70% of chips, and some don‘t work at all.
Has anybody the same problem?
Are those chips suffering from ESD?
Or do they have some problem with powersupply or do they latch up more
easily?
Do failiures affect 9572-15, or also other types?
Jedec‘s are not under suspect anymore: Failiures are seen also in
designs
without any asynchronous path at all.

Any hints appreciated.
BR
Genio



Article: 19551
Subject: Re: USB2 core call for Volunteers
From: mcjy@my-deja.com
Date: Thu, 30 Dec 1999 11:37:21 GMT
Links: << >>  << T >>  << A >>
Thanks for the information. :-)
I will try to find the book you mentioned.

from
Joe



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19552
Subject: Re: USB2 core call for Volunteers
From: mcjy@my-deja.com
Date: Thu, 30 Dec 1999 11:53:00 GMT
Links: << >>  << T >>  << A >>
From the message posted by Steen Larsen,
it seems that it is very difficult for OpenCore
project to work on latest version of PCI
right from the start. So maybe we can
just concentrate on PCI 2.x using 33MHz
and 32 bit? :-)



In article <84e8da$1ae2$1@noao.edu>,
  "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> wrote:
> Magnus Homann wrote in message ...
> >"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes:
> >
> >> mcjy@my-deja.com wrote in message <84cs87$k4m$1@nnrp1.deja.com>...
> >>
> >> >For PCI core, now the market is moving
> >> >to PCI-133. But prototyping (for testing)
> >> >can be a big problem. Most FPGAs/CPLDs only
> >> >support up to PCI 66.  In addition, I think
> >> >that we need to "buy" PCI specification
> >> >document. Is it still true?
> >>
> >> Methinks you're confusing the PC-133 memory standard with PCI.  The
> fastest
> >> PCI standard is 66 MHz and a 64-bit-wide data/address bus.
> >
> >He might be talking about PCI-X. I've heard rumours that FPGA vendors
> >are looking into it.
>
> I just checked the web site Joe referred to.  I stand corrected!
>
> I have the Mindshare book but I haven't had a chance to do much more
than
> glance at it.
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> The secret of Slurm is on a need-to-know basis.
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19553
Subject: Re: USB2 core call for Volunteers
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 30 Dec 1999 13:34:45 +0100
Links: << >>  << T >>  << A >>
mcjy@my-deja.com writes:

> From the message posted by Steen Larsen,
> it seems that it is very difficult for OpenCore
> project to work on latest version of PCI
> right from the start. So maybe we can
> just concentrate on PCI 2.x using 33MHz
> and 32 bit? :-)

The PCI 2.2 spec _replaces_ the PCI 2.1.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 19554
Subject: Re: License of Atmel free CD ROM Software
From: dmac <dmac@cutme.matter200.demon.co.uk>
Date: Thu, 30 Dec 1999 14:35:31 +0000
Links: << >>  << T >>  << A >>
Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid> writes
>Hi friends,
>I have now got CD from Actel with actel software, veribest and synplify
>But I can't make it working. After Actel dectop run it says: "Error
>reading licens file"!
>Have to get extra licens?
>(I have found  nothing about this in Documentation)

Extract from win95.htm in root on Actel Desktop CD V1.1, March 1999,
(305922R1)

"Obtaining a License
Use the following procedure to obtain a license to run the Actel DeskTOP
software: 
1. Click the "License Registration" button from the CD start-up browser
screen. 
2. Fill in the information requested by the licensing application.
3. Paste the information from the clipboard into an e-mail and send to
desktop@actel.com. Do not send the information as an attachment to the
email.
4. License requests must be sent as the text of an email. 
Your license will be e-mailed to you in about 1 day. "

-- 
dmac
Article: 19555
Subject: Re: Virtex Config Help
From: Timothy Miller <tim@techsource.com>
Date: Thu, 30 Dec 1999 15:34:22 GMT
Links: << >>  << T >>  << A >>
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.
Article: 19556
Subject: Re: PCI slot 3.3V pins.
From: "Austin Franklin" <austin@d33arkroom.com>
Date: 30 Dec 1999 22:10:06 GMT
Links: << >>  << T >>  << A >>
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....

Just my opinion...

Article: 19557
Subject: Bad ALTERA data
From: "IC-BOOK" <food@alik.carrier.kiev.ua>
Date: Fri, 31 Dec 1999 00:45:41 +0200
Links: << >>  << T >>  << A >>
Dear All.


I never programm ALTERA's MAX7000 before.
What will do with EPM7064SLC (for exemple)
if I programm it with mistaked data and
after programm plug card with that chip
to computer's slot.
(I programm it by ISP)
MAX will crash?

When I programm GAL20V10 with mistaked data,
that the computer would not started, but
GAL and computer were alive.

Does everyone has some experience?

Thanks.

Alexandr Kouchtch
Entry Ltd.
http://ic.book.kiev.ua


Article: 19558
Subject: Foundation 2.1i Synthesis->Options One-Hot/Zero-Hot state machine encoding
From: "Matt Billenstein" <mbillens@one.net>
Date: Thu, 30 Dec 1999 23:08:40 GMT
Links: << >>  << T >>  << A >>
I noticed they've added the option to encode state machines Zero-Hot in the
latest Foundation release...  what's the advantage if any to this?  Does it
just remove a level of logic if your state machine drives negative logic
outputs?  Does it make state transitions faster or anything like that?

thx

m


Matt Billenstein
http://w3.one.net/~mbillens/
REMOVEmbillens@one.net




Article: 19559
Subject: Using internal RAM in Altera Flex 10KE
From: "MK Yap" <mkyap@ieee.org>
Date: Fri, 31 Dec 1999 12:53:14 +0800
Links: << >>  << T >>  << A >>
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


Article: 19560
Subject: Re: Using internal RAM in Altera Flex 10KE
From: mcjy@my-deja.com
Date: Fri, 31 Dec 1999 09:34:30 GMT
Links: << >>  << T >>  << A >>
You need to use the LPM library components.

On your on-line help in Maxplus 2, you can see
items like lpm_ram_dq and some other RAM components.

To use these components, you also need
to include the LPM libraries. (There are examples
in the help.)

from
Joe


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: 19561
Subject: code error in active vhdl
From: "Mariotto" <mariotto@libero.it>
Date: Fri, 31 Dec 1999 09:53:37 GMT
Links: << >>  << T >>  << A >>
Hallo all

whoever knows how to explain me that type of error is the following (Active
[vhdl]):

Error: ELBWRITE_0001: combfiltvht.vhd : (88, 0): INTERNAL ERROR:
mbeflib.cpp(6691).

found while I built the library for the Coregen.

Thanks

Claudio Casagrande
DSP lab.
Univ. of Perugia
Italy
mariotto@libero.it



Article: 19562
Subject: Re: PCI slot 3.3V pins.
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 31 Dec 1999 11:08:34 +0100
Links: << >>  << T >>  << A >>
"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
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 19563
Subject: Design security
From: "Larry Edington" <larryeSpam.Me.Not@centuryinter.net>
Date: Fri, 31 Dec 1999 11:20:44 -0600
Links: << >>  << T >>  << A >>
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.




Article: 19564
Subject: Re: Design security
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 31 Dec 1999 17:32:35 GMT
Links: << >>  << T >>  << A >>
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.

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

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 19565
Subject: Design security
From: "Number Cruncher" <michel.heuts@pandora.be>
Date: Fri, 31 Dec 1999 18:42:25 +0100
Links: << >>  << T >>  << A >>
Larry,

            depending on the total gate count you could
consider using Actel's ProAsic SX... family (100k gates) or
Lattice's 2000/5000/8000 family (42k)

These offer 100% IP protection (if the security bit is on ...).

Things depend upon whether you are talking about 100 pieces
or 100k pieces, the latter I would return to an Asic approach.


look at:    www.optimagic.com
                www.actel.com
                www.latticesemi.com    (Lattice Semi Corp & Vantis Corp.)

regards,

Michel HEUTS
WMU Belgium




Article: 19566
Subject: Re: Design security
From: Phil Hays <Spampostmaster@sprynet.com>
Date: Fri, 31 Dec 1999 11:32:06 -0800
Links: << >>  << T >>  << A >>
Larry Edington wrote:

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

An alternative might be to program the FPGA from the host computer.  What
prevents someone from copying your software and using it somewhere else?  There
are several means (like putting an unique numbers generated by the program into
RAM) to customize the bitstream in the host computer to make sure that the FPGA
will not function without the host software.  BTW, this just moves the problem. 
How do you protect the software?

This has another advantage: you can change the encryption / decryption function
by just updating the software for your authorized users.


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

It isn't easy to reverse engineer the configuration bit stream.  Some parts of
the configuration are "public", like the initial contents of RAM locations,
making them
easy to customize for each download.  Some parts are not, such as the
interconnect programing.  Picture your design as a pile of logic gates with the
wires gone.  To fill in the wires would take a large and determined effort.

Who are you trying to protect against, and why, and for how long?  This is going
to determine the levels and kinds of protection you need.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 19567
Subject: Re: Design security
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 31 Dec 1999 15:52:26 -0800
Links: << >>  << T >>  << A >>
I agree. I wrote an app note (XAPP092, page 14-40...43 in the 99 Xilinx data
book) that describes the alternatives in a bit more detail.
Happy New Year!
Peter Alfke, Xilinx Applications
===================================================

"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.
>
> >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.
>
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 19568
Subject: Re: Using internal RAM in Altera Flex 10KE
From: "Michael Vincze" <vincze@home.com>
Date: Sat, 01 Jan 2000 00:25:19 GMT
Links: << >>  << T >>  << A >>
Joe had suggested using LPMs.  Which is a nice choice.

In order to use the RAMs, you need to use the EABs.  As
a side note, the EABs may also be used for decode logic.
At least last year MaxPlus2 was not capable of synthesizing
EABs (i.e.:  If you had a decoder that would fit into an
EAB it would not place it in the EAB automatically, unless
you explicitly instantiated it.)  I suspect this had not
changed.

Other than using LPMs, Altera offers some type of
macro generator that allows you to instantiate
logic into the EABs.  Sorry I can't recall off the
top of my head how its done, but it does take
a few steps to set up.  The process incolves
generating VHDL for simulation, and some
form of netlist for synthesis.  Take a look in their
bin directory for the executable that does it,
and of course look in the Altera documentation.

I've never tried the LPM solution, but it is
probably closer to a "technology independent
solution", so it may be more attractive.

Good luck,
Michael


MK Yap <mkyap@ieee.org> wrote in message
news:84hclo$ob8$1@clematis.singnet.com.sg...
> 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
>
>


Article: 19569
Subject: Re: An online division unit with constant divisor
From: Russell Coggrave <c.r.coggrave@lboro.ac.uk>
Date: Sat, 01 Jan 2000 15:20:01 +0000
Links: << >>  << T >>  << A >>
Terje Mathisen wrote:

> Kelly Hall wrote:
> >
> > On Wed, 29 Dec 1999 15:45:20 -0000, J.R. <j_robby@hotmail.com> wrote:
> > >Does anybody know where I can find an algorithm for Radix-2 online division
> > >(Radix-2  serial Signed Digit arithmetic) with a constant divisor. I need
> > >such a unit for a hardware implementation onXC4000 FPGA. I had a look at
> > >Ercegovac's book entitled " Digit Recurrence algorithms and implementations"
> > >but have not found a special algorithm for constant divisor. If someone can
> > >point me directly to an FPGA implementation, that would be great! :-)
> >
> > If you are dividing by a constant, can't you just multiply by the
> > reciprocal instead?  Implementing a constant multiplier boils
> > down into some adder trees with various shifts of the input word.
>
> Right.
>
> It can be proven that any N-bit / N-bit -> N-bit division can be
> emulated exactly with a truncated/scaled multiplication by a reciprocal
> constant with at the most N+1 significant bits.
>
> The simplest algorithm to locate this constant is to first locate the
> nearest power of two which is smaller than the divisor, shift this
> number left by N bits and then divide by the divisor.
>
> If the remainder is greater than half the divisor, then simply increment
> the N-bit division result for and N-bit reciprocal.
>
> Otherwise, you need to add an extra 1 bit at the end, giving a (N+1) bit
> reciprocal.
>
> To use this, simply multiply by the reciprocal and shift right to
> correct for the initial scaling of the reciprocal.
>
> Terje
>
> --
> - <Terje.Mathisen@hda.hydro.com>
> Using self-discipline, see http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in caching"

Any chance of a simple example or reference to the proof Terje ?

Thanks,

Russ


Article: 19570
Subject: Re: Design security
From: "Larry Edington" <larryeSpam.Me.Not@centuryinter.net>
Date: Sat, 1 Jan 2000 09:28:36 -0600
Links: << >>  << T >>  << A >>
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.
>
>
>
>


Article: 19571
Subject: Re: Design security
From: Jonathan Bromley <jonathan@oxfordbromley.u-net.com>
Date: Sat, 01 Jan 2000 17:57:45 +0000
Links: << >>  << T >>  << A >>
Larry Edington 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.

I agree.
 
> 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?

Yes, you are entirely correct. OTOH a clone of your programmed FPGA is
likely useless without either your documentation, or the board (and
its host software) on which your FPGA resides.  So one possible approach
is to protect the design and/or software of everything *except* the 
FPGA, and make sure the FPGA has a reasonably arcane interface so it's
very difficult to reverse engineer its *behaviour*.

In this way, you're putting yourself in the same position as 
if you had just discovered that some manufacturer's wonder-IC 
did exactly what you need.  So you design a killer product 
around that wonder-IC.  But once the pirates have opened your
box they can easily buy a new copy of the wonder-IC.  How do 
you protect your product investment?  Answer:  code-protected 
microcontrollers, tricksy hidden wiring, all the usual stuff.

> If a device programmer
> couldn't read it as well then this would be sufficient for my design.

I doubt it.  If the FPGA can read the bitstream during config,
then anyone else can do likewise.  Indeed, it is always possible to
tap in to the bitstream *during* configuration and read it that way,
so you don't need to pull the EPROM from the circuit.

It's probably been mentioned already in this thread, but 
I'll mention it anyway:  the *only* way to protect an SRAM FPGA
effectively is to download config to it at a secure site, then
rely on battery backup to keep it alive.  Used by the military
for one-shot devices (cruise missiles etc).  Or go for an
antifuse solution.

Jonathan Bromley
Article: 19572
Subject: Re: PCI slot 3.3V pins.
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sat, 1 Jan 2000 10:57:11 -0800
Links: << >>  << T >>  << A >>
Austin Franklin <austin@darkroo99m.com> wrote in message
news:01bf5281$f4c73ce0$207079c0@drt1...
>
> A 5V card will not work in a slot keyed for 3.3V, nor will a 3.3V card
work
> in a slot keyed for 5V.  A universal card will work in either, but as I
> said, I don't believe there are any 'main stream' cards being made to be a
> PCI universal card...

Actually, not too long ago at work we had occasion to dig around and try to
find some universal cards.   The only two we found were both Ethernet
cards... an Intel EtherExpress and a NetGear FA310TX.

I would say that I've never seen a 3.3V-only card!

> 66MHz does require 3.3V signaling though...and does not support 5V
> signaling.

A lot of the potential power of 66MHz PCI seems to be wasted due to what
appear to currently only be point to point connections (chipset to one, and
only one, 66MHz PCI slot).  Hopefully this will change in a future revision
of PCI (PCIx?).

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

LT1587s (and clones thereof) seem very popular for this task.

---Joel Kolstad



Article: 19573
Subject: Re: code error in active vhdl
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sat, 1 Jan 2000 11:07:45 -0800
Links: << >>  << T >>  << A >>
Mariotto <mariotto@libero.it> wrote in message
news:B2%a4.1910$Oo1.29441@news.infostrada.it...
> Hallo all
>
> whoever knows how to explain me that type of error is the following
(Active
> [vhdl]):

You'll probably need to send us (or Aldec) your code.  In my experience,
Internal Errors in ActiveHDL are caused when ActiveHDL thinks you're trying
to be excessively clever about something, when in reality you probably just
have a syntax error.  I've also seen it bomb if you've been compiling things
out of order, and it runs off and tries to bind, say, a more recently
compiled file with a newer component declaration to an older actual
component.  In this case, go over to the library manager, empty the library,
and re-compile everything in the proper order.

---Joel Kolstad



Article: 19574
Subject: Re: Design security
From: "Number Cruncher" <michel.heuts@pandora.be>
Date: Sat, 1 Jan 2000 21:09:00 +0100
Links: << >>  << T >>  << A >>
Larry,

            apart from using large (deterministic and fast) 42k - 100k gates
CPLDs with internal configuration memory
(Cypress Delta 39k - Actel ProAsic - Lattice 5000/8000 - Xilinx XPLA -
Vantis 'Godfather family') you could ask yourself
if an additional 0.50$ US Microchip or XC76041 Xicor secure E˛PROM could
give you the utmost security.

You could place an algorithm/state machine in your CPLD/FPGA communicating
with the secure Microchip PIC12Cxxx or
Xicor device - the addition of a random communication scheme could enhance
security. (depending on what the micro
sends the state machine could answer encrypted) that way wecurity is burned
in your CPLD and microcontroller sensing the
right CPLD/FPGA. (The User Encryption Signature is not part of the protected
region and is public accessible).

One secure microchip of 0.50 US $ could be a very big advantage against
expensive SRAM devices ...

Also note that configuration memory is sold (too) expensively.

regards,

Michel HEUTS
WMU Belgium


http://www.optimagic.com





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




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