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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 26700

Article: 26700
Subject: Re: How safe is the algorithm implemented with FPGA?
From: steve (Steve Rencontre)
Date: Wed, 25 Oct 2000 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <39f6ac87.8065038@news.dial.pipex.com>, 
eml@riverside-machines.com.NOSPAM () wrote:

> On Fri, 20 Oct 2000 10:12:50 GMT, kolja@prowokulta.org wrote:
> 
> >So, what is left:
> >New algorithms invented by you and secret parts of known algorithms,
> >such as decryption keys.
> >Especially for the latter paranoid protection could be useful.
> >But, as Nick pointed out, that's almost impossible to achieve.
> >There is - expensive - equipment that can read the content of SRAM
> >cells. This would even break Xilinx Virtex-II DES approach.
> 
> What do you mean by 'even break Xilinx Virtex-II DES approach'? Sounds
> like you know something we don't know...

The DES encryption only protects the config bit stream. If you take the 
lid off the chip and look at the SRAM contents, you're looking at the 
decrypted result.

The only way to be completely secure against the dedicated cracker is to 
have a programming element in which the on and off states can't be 
distinguished. Of course, that's a self-contradictory requirement, short 
of some as-yet unimagined quantum device :-)

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 26701
Subject: Re: How safe is the algorithm implemented with FPGA?
From: "Keith R. Williams" <krw@btv.ibm.com>
Date: Wed, 25 Oct 2000 14:10:00 -0400
Links: << >>  << T >>  << A >>


Nicholas Weaver wrote:
> 
> In article <8t2evsoh4jbg8guso10o1drhljl391dsum@4ax.com>,
> Philip Freidin  <philip@fliptronics.com> wrote:
> 
> > First I believe that triple-DES requires 3 keys, each of 56 bits
> > (plus parity), so my guess is that the EDN article should say that
> > the chip holds two sets of three 56-bit keys.
> 
>         No, 3DES only uses 2 keys, A and B.  The procedure for
> encrypting a block is E(D(E(data,A),B),A).  So you encrypt with key A,
> decrypt the result with key B, and then reencrypt with key A, so you
> are going through the DES function 3 times, but with only 2 keys.

In the classical triple DES, yes.  I've been out of crypto for seven
years (I did physical security and key management hardware).  However,
IIRCt there was some worry that this might be subject to a "meet in the
middle" attack on the two keys. So a three-key "standard" was adopted.  

> >As for your slides, my guess is that at the time you received it, the DES
> >stuff was on their NDA list of features. The EDN article now
> >publicly discloses this information.
> 
>         I suspect that as well.  If so, this will be a very useful
> feature, although it will be interesting to see how it can be
> attacked.

One way, though it may be considered rather extreme, is to fry the chip
with X-rays.  CMOS SRAM tends to "harden" into it's current state when
bombarded with X-rays. When powered on, it'll then tend to come up in
that state.  IFAIK this isn't perfect, but any bits recovered reduce the
effort to crack the key greatly. 

Of course there may be other holes as well. Depending on the level (as
in FIPS 140 level) you get into, the crypto "Spy vs. Spy" game can get
very interesting, even when not working for a *government* three
lettered organization.

----
  Keith R. Williams
  Not speaking for IBM (I doubt they know I can speak)

Article: 26702
Subject: Re: How safe is the algorithm implemented with FPGA?
From: nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver)
Date: 25 Oct 2000 18:35:42 GMT
Links: << >>  << T >>  << A >>
In article <39F721F8.1457F1AA@btv.ibm.com>,
Keith R. Williams <krw@btv.ibm.com> wrote:
>Of course there may be other holes as well. Depending on the level (as
>in FIPS 140 level) you get into, the crypto "Spy vs. Spy" game can get
>very interesting, even when not working for a *government* three
>lettered organization.

	Yeah.  I'm not a security expert myself, but it is fun to just
watch and see what people are capable of doing.  That, and it is fun
to listen to NSA guys talk about customers.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 26703
Subject: Re: How safe is the algorithm implemented with FPGA?
From: nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver)
Date: 25 Oct 2000 18:43:47 GMT
Links: << >>  << T >>  << A >>
In article <memo.20001025184516.1288X@steve.rsn-tech.co.uk>,
Steve Rencontre <steve@rsn-tech.co.uk> wrote:
>The DES encryption only protects the config bit stream. If you take the 
>lid off the chip and look at the SRAM contents, you're looking at the 
>decrypted result.

	Of course, if you take the lid off, just read out the key and
you don't need to bother reading out the SRAM contents of the whole
chip.

>The only way to be completely secure against the dedicated cracker is to 
>have a programming element in which the on and off states can't be 
>distinguished. Of course, that's a self-contradictory requirement, short 
>of some as-yet unimagined quantum device :-)

	OR, you just don't let the attacker get the box.  :)

	Although you COLUD make the stakes higher by embedding your
chip in a large quantity of high explosive (or nerve gas, or something
else similarly nasty), encased in a very fine sensor mesh and covered
in solid plastic, REALLY hard to get at and well, an error on the
attacker's part would be a bit catastrophic.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 26704
Subject: Re: How safe is the algorithm implemented with FPGA?
From: Brian Dipert <bdipert@NOSPAM.pacbell.net>
Date: Wed, 25 Oct 2000 11:44:15 -0700
Links: << >>  << T >>  << A >>
>I spoke to someone at Xilinx about this, and he confirmed that to the
>extent of the article, what is disclosed is now public, and Brian Dipert
>did not reveal stuff he shouldn't have under some NDA.

Philip, Philip, Philip....you didn't think I was misbehaving, did you?
;-) Yes, my article marked the first public disclosure of Triple DES
support in Virtex-II

Brian Dipert
Technical Editor: Memory, Multimedia and Programmable Logic
EDN Magazine: http://www.ednmag.com
Contributing Editor, CommVerge Magazine: http://www.commvergemag.com
1864 52nd Street
Sacramento, CA   95819
(916) 454-5242 (voice), (916) 454-5101 (fax)
***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY***
mailto:bdipert@NOSPAM.pacbell.net
Visit me at http://members.aol.com/bdipert

Article: 26705
Subject: Re: Design theft story in EDN. New security ?
From: Brian Dipert <bdipert@NOSPAM.pacbell.net>
Date: Wed, 25 Oct 2000 11:50:03 -0700
Links: << >>  << T >>  << A >>
>just look in deja for design security.  This has been hashed over many times on
>the newsgroup.  Frankly, I think Brian got alot of his material from the
>discussions here too, as I recognize a good deal of it.  

Howdy Ray, the comp.arch.fpga discussion thread mentioned in my
article was indeed the original motivation for this article (though I
did get a 'bit' more material through my more recent research;
implying that I relied on comp.arch.fpga discussions 'a lot' is
perhaps overstating reality 'a lot'). ;-)

'A lot' of discussion threads here find their way into my articles, as
inspiration for topics if nothing else. After all, why waste my time
writing on stuff that isn't of interest to y'all? ;-)

Brian Dipert
Technical Editor: Memory, Multimedia and Programmable Logic
EDN Magazine: http://www.ednmag.com
Contributing Editor, CommVerge Magazine: http://www.commvergemag.com
1864 52nd Street
Sacramento, CA   95819
(916) 454-5242 (voice), (916) 454-5101 (fax)
***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY***
mailto:bdipert@NOSPAM.pacbell.net
Visit me at http://members.aol.com/bdipert

Article: 26706
Subject: Re: How safe is the algorithm implemented with FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Oct 2000 18:57:44 GMT
Links: << >>  << T >>  << A >>
Makes you wonder where he got his info ;->

eml@riverside-machines.com.NOSPAM wrote:
> 
> On Wed, 25 Oct 2000 09:49:32 GMT, eml@riverside-machines.com.NOSPAM
> wrote:
> 
> >On Fri, 20 Oct 2000 10:12:50 GMT, kolja@prowokulta.org wrote:
> >
> >>So, what is left:
> >>New algorithms invented by you and secret parts of known algorithms,
> >>such as decryption keys.
> >>Especially for the latter paranoid protection could be useful.
> >>But, as Nick pointed out, that's almost impossible to achieve.
> >>There is - expensive - equipment that can read the content of SRAM
> >>cells. This would even break Xilinx Virtex-II DES approach.
> >
> >What do you mean by 'even break Xilinx Virtex-II DES approach'? Sounds
> >like you know something we don't know...
> 
> I just answered my own question by reading the EDN article. According
> to the article, Virtex-II includes "a hard-wired Triple-DES decryption
> block, along with two sets of 56-bit key registers and dedicated
> battery-backup supply-voltage inputs for only those registers, on its
> upcoming Virtex-II FPGAs".
> 
> Funny thing is, though, that I was at a seminar two weeks ago, and
> this wasn't mentioned. I've got 29 pages of slides on Virtex-II, and
> not one of them mentions a triple-DES block, which isn't the sort of
> thing you'd accidentally leave out of a presentation.
> 
> Anyone know any more?
> 
> Evan

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 26707
Subject: Re: 155Mhz DDR in a programmable logic
From: "Pete Dudley" <padudle@sandia.gov>
Date: Wed, 25 Oct 2000 13:01:44 -0600
Links: << >>  << T >>  << A >>
155MHz DDR should be cake in a Virtex part. I'm doing 622 Mword/sec
signalling using the lvds I/O on the VirtexE. Search for LVDS on the Xilinx
Web page and you'll find an app. note that shows how to do it all.

At 155MHz you should be able to use the LVTTL i/o if you want.

Buena Suerte.

<gazit@my-deja.com> wrote in message news:8t6cf6$veu$1@nnrp1.deja.com...
> Does anyone think it is possible to drive DDR (Double Data Rate) bus at
> 155Mhz from/to a programmable logic device  ?
> In DDR bus the data changes on both clock edges.
> My application is half-duplex : separate driver and receiver pins.
>
> Thanks in advance for your comments,
> Rotem.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.



Article: 26708
Subject: ROC (reset on configuration) on Virtex ?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: 25 Oct 2000 19:21:44 GMT
Links: << >>  << T >>  << A >>
hi,
I need an external reset and an internal power on reset type signal.
In Synplicity libraries, there is a ROC cell for Virtex but there are
no simulation libraries in Alliance toolset for ROC. Is this cell
valid for Virtex ? I am also using a DLL. Is there a way to make sure
that ROC doesn't go low before LOCK happens ? Also what is the timing
for ROC signal after a configuration ?

thanks,

Muzaffer
http://www.dspia.com

Article: 26709
Subject: Re: How safe is the algorithm implemented with FPGA?
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 25 Oct 2000 19:51:15 GMT
Links: << >>  << T >>  << A >>
On Wed, 25 Oct 2000 09:55:14 -0700, Philip Freidin
<philip@fliptronics.com> wrote:

>On Wed, 25 Oct 2000 13:59:28 GMT, eml@riverside-machines.com.NOSPAM wrote:
>>I just answered my own question by reading the EDN article. According
>>to the article, Virtex-II includes "a hard-wired Triple-DES decryption
>>block, along with two sets of 56-bit key registers and dedicated
>>battery-backup supply-voltage inputs for only those registers, on its
>>upcoming Virtex-II FPGAs".
>>
>>Funny thing is, though, that I was at a seminar two weeks ago, and
>>this wasn't mentioned. I've got 29 pages of slides on Virtex-II, and
>>not one of them mentions a triple-DES block, which isn't the sort of
>>thing you'd accidentally leave out of a presentation.
>>
>>Anyone know any more?
>>
>>Evan 
>
>First I believe that triple-DES requires 3 keys, each of 56 bits (plus parity),
>so my guess is that the EDN article should say that the chip holds two
>sets of three 56-bit keys.

I actually did a Xilinx 3DES a couple of months ago. Unfortunately,
'triple-DES' is not well-defined. The basic DES algorithm is
straightforward, but it's only half the problem. The rest is that you
have to decide a mode in which you want to use it, which involves
things like data chaining and feedback around the DES block, and how
many times you want to run data through DES itself. As Keith says,
3DES was originally done with 2 keys, but there was a concern that
there was a symmetry problem that effectively made this one-key, which
is easily crackable. According to Schneier's book this was eventually
disproved, but he still recommends using 3 different keys for maximum
security. Fortunately the hardware's identical - I just have three
56-bit key registers instead of 2, and select either the 1st or 3rd
register for the final pass.

And, of course, DES's successor - Rijndael - has turned up since I
finished, so I'm just waiting to be told to throw it all away and
start again.

>As for your slides, my guess is that at the time you received it, the DES
>stuff was on their NDA list of features. The EDN article now
>publicly discloses this information. 
>
>(I searched the Xilinx web site, and could not find any supporting info
>about this capability.)
>
>I spoke to someone at Xilinx about this, and he confirmed that to the
>extent of the article, what is disclosed is now public, and Brian Dipert
>did not reveal stuff he shouldn't have under some NDA.

I expect you're right. It does seem rather odd though - it was NDA'ed
2 weeks ago and suddenly turns up in the press, which smells somewhat
like a cock-up.

Evan

Article: 26710
Subject: Re: How safe is the algorithm implemented with FPGA?
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 25 Oct 2000 19:52:20 GMT
Links: << >>  << T >>  << A >>
On 25 Oct 2000 17:43:34 GMT, nweaver@soda.CSUA.Berkeley.EDU (Nicholas
Weaver) wrote:

>	I suspect that as well.  If so, this will be a very useful
>feature, although it will be interesting to see how it can be
>attacked.

A couple of things occur to me - if this feature actually exists,
we'll need some way to find out if the power has been disconnected and
if the key contents have leaked away. How is this going to be done? Do
we just rely on DONE not going active? You obviously can't read the
keys back to see if they're still Ok.

Next problem: what do you do if the power *has* been disconnected, or
the keys have become corrupted in some way? You want to supply new
keys to the customer, preferably without getting the board back. You
have to set up a secure key exchange with them, using public-key
encryption. This takes some organising, but is well understood.
**But:**

At some point the new secret keys are decoded locally at the
customer's site, and must be programmed back into the FPGA *in the
clear*. In other words, if the customer has the ability to fix the
power-fail problem, then there will always be a point at which the
'secret' keys can be probed on the board. So the customer can't fix
the problem on-site, and must return the board. If this is true, It
begs the question of whether a separately-powered SRAM-based key is
actually very much better than a separately-powered complete FPGA.

>	On the slides, did they have any information on partial
>reconfigurability on the Virtex 2?

Afraid not. Mainly faster, bigger, better, more memory, multipliers,
interesting clocking and routing, 800Mbps LVDS, bigger CLBs. I think
most, if not all of this, is on the website.

Evan

Article: 26711
Subject: Re: How safe is the algorithm implemented with FPGA?
From: nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver)
Date: 25 Oct 2000 20:12:16 GMT
Links: << >>  << T >>  << A >>
In article <39f73974.44147987@news.dial.pipex.com>,
 <eml@riverside-machines.com.NOSPAM> wrote:
>And, of course, DES's successor - Rijndael - has turned up since I
>finished, so I'm just waiting to be told to throw it all away and
>start again.

	Rijndael is a NICE algorithm, especially with the Virtex
BlockRAMs exactly matching the space required to store both the
encryption and decryption S-boxes, a full round implementation is
incredibly fast, and compact implementations give a good
area/performance tradeoff.

	The paper can be hard to read, because it presents the
mathematical background first, but the algorithm itself is nice and
simple.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 26712
Subject: Re: How safe is the algorithm implemented with FPGA?
From: nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver)
Date: 25 Oct 2000 20:25:39 GMT
Links: << >>  << T >>  << A >>
In article <39f739b5.44213007@news.dial.pipex.com>,
 <eml@riverside-machines.com.NOSPAM> wrote:
>Next problem: what do you do if the power *has* been disconnected, or
>the keys have become corrupted in some way? You want to supply new
>keys to the customer, preferably without getting the board back. You
>have to set up a secure key exchange with them, using public-key
>encryption. This takes some organising, but is well understood.
>**But:**

	Since it is symmetric key, independantly battery backed up,
you MUST get the board back and reprogram it yourself, or trust your
customer.  There is no way around this problem.  But if you trusted
your customer, you wouldn't need or use this feature.  With only the
symmetric key cryptographic algorithm and with the key in the device
lost, there is no other approach, as you correctly noted in the later
paragraph (munched for space).

	The key is to make it as idiot-proof-as-possible with regards
to the power supply, something like a 10 year key lifespan on a
single, small, Lithium-ion battery, with an additional slot to put
ANOTHER battery if the main battery ever needs to be replaced.  If the
device lifetime is less than the battery, something like coating the
battery with a blob of epoxy might be useful.

>the problem on-site, and must return the board. If this is true, It
>begs the question of whether a separately-powered SRAM-based key is
>actually very much better than a separately-powered complete FPGA.

	It is, for the following reasons:

	1) Only having to store the key bits really reduces the power
demand.  So it is reasonable to expect the device to maintain its keys
for a decade+ with a very small battery.  This is NOT possible if the
whole device must remained powered, even in a low power quiescent
state.

	2) Independant power pins and power plane on the chip for the
battery backup greatly simplify the implementation.  If I need the
whole FPGA to run on battery backup, I need a mechanism to switch
between the normal power supply and battery, the FPGA needs to exist
on a purely separate power plane, my bitfile MUST shutdown all I/Os
into high impedance mode and clock and all activity when the power is
switched.  

	This model only requires that I hook up a battery to 2
specific pins on the device, with no other external or internal logic
required, yet it brings security ALMOST to the level of a battery
backed up device with the configuration loaded/always on.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 26713
Subject: Re: Jtag programing 18V02 prom
From: Arthur Yang <arthur.yang@xilinx.com>
Date: Wed, 25 Oct 2000 13:33:13 -0700
Links: << >>  << T >>  << A >>
Hello Stephen -

  Make sure you select an 18V02PC44 as opposed to an 1802PC44.

  Regards,
  Arthur

Stephen Lohning wrote:

> I have been trying to program the XC18V02 xilinx prom via jtag without
> any success.
> The JTAG programmer WebPACK 3.1WP@.x
> Application version D.21 doesn't seem to regnize the part properly.
> The part  is the XC18v02_pc44 I think there is a mistake in the
> associated bsd file
>
> attribute IDCODE_REGISTER of XC1802_pc44: entity is
>         "0000" &                -- version
>         "0101000000000101" &    -- part number
>         "00001001001" &         -- manufacturer's id
>         "1";                    -- required by standard


Article: 26714
Subject: Re: How safe is the algorithm implemented with FPGA?
From: kolja@prowokulta.org
Date: Wed, 25 Oct 2000 21:14:31 GMT
Links: << >>  << T >>  << A >>
1.
If there is SIGNIFICANT economic interest in reverse engineering the
design. The eqipment to go around the DES would not be any problem.
Just open up the chip.
Solution 1:
Get it into an asic tester and observer the triple DES input and output.
This gives you the key and the decrypted bitstream.
Solution 2:
Observe the state of the SRAM cells under an electron microscope.
Could be hard with 7 layer metal, but you can do it for only $10k

2.
If you now the full functionality of the chip, a redesign is probably
easier than the reverse engineering. But you might want to have
100% compatibility and your competitor just won't send you the spec.
But in any case, from observing the chip you can guess about the
functionality of a part of it.
You can then use formal verification software to extract the
corresponding circuit from the stolen netlist. This gives you a
smaller remaining netlist that you can observe and again guess
on part of the functionality. Some automatic reasoning, and so on...

It is just a matter of the right tools.

CU,
      Kolja



In article <39F58D51.1C14B0B6@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> True enough, but that is only the first step (and arguably the easiest
step) of
> reverse engineering a design from the bitstream.  Once the design is
> reconstituted as a netlist of LUTs, you have essentially a flat
representation
> of the design with LUTs, FF's and carry chain elements as its only
primitives.
> WHile this can be reverse engineered, the effort to do so is
substantial even
> for small devices (I know, I had to  discover the function of a 2064 a
few years
> ago for a client...that one only has 64 very simple logic cells and it
was no
> small effort)  The effort to do the discovery was at least 3x the
effort for a
> design from scratch.  I suspect that effort goes up faster than linear
as the
> number and complexity of the LUTs is increased.
>
> So the bottom line is the tools out there now make it possible to
recover the
> flat primitive level design, which is essentially what you get if you
capture
> the backannotated netlist from the tools (uses simprim library).
Getting that
> netlist into a form that allows you to understand the design is
another matter
> altogether.  To get an idea of the effort it would take, take a *.vho
output
> from the placer on one of your designs and try to figure out from
there how it
> works.  It's not trivial even when you know the design!

> >         And, with a tool like Jbits for the Virtex, it is pretty
> > reasonable to go from a bitfile to a technology mapped (lut mapped)
> > netlist.
> >
> >         The result can be pretty hard to understand, with
obsfucation
> > and other confusion, but going from bitfile->lut mapped netlist is a
> > reasonable operation.  If there is a SIGNIFICANT ecomonic interest
for


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26715
Subject: Re: log2 function in VHDL
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Wed, 25 Oct 2000 23:41:29 +0200
Links: << >>  << T >>  << A >>
Try this one which I happened to write Yesterday !
It is not general purpose, but it is good enough for the intended use
and does not use nasty divisions...



library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
library WORK;
use WORK.all;
package MATH is
function LOG2(MAXADDRESS : INTEGER) return INTEGER;
end MATH;

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
library WORK;
use WORK.all;
package body MATH is
-- Will work for up to 32 bit
function LOG2(MAXADDRESS : INTEGER) return INTEGER is
variable temp  : INTEGER;
begin
 temp := 2;
 for I in 1 to 31 loop
  if(temp > MAXADDRESS) then
   return I;
  end if;
  temp := temp + temp;
 end loop;
 return 32;
end;

end MATH;


--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden

"Peter Lang" <Peter.Lang@rmvmachinevision.de> wrote in message
news:8t6m9d$abi$00$1@news.t-online.com...
> Hi,
> I am doing my first steps in VHDL.
> I wanted to implement a log2-function using
> Xilinx Foundation 3.1i with Synopsis FPGA Express 3.4.
> I tried the following source-code, which I found here in the newsgroup.
> But the Compiler found an error
>
> Dpm: Error: Non-static loop or event waits in only some branches detected
>
> I have no idea whats wrong.
>
>
> package MATH is
>    function log2 ( num : integer) return integer;
> end MATH;
>
> package body MATH is
>   function log2 ( num : integer) return integer is
>     variable diviser : integer;                           -- Divided to
form
> result
>     variable acc     : integer;                             -- accumulates
> result
>   begin
>     diviser := num;
>     acc := 0;
>     LogLoop : while (diviser >= 2) loop
>       diviser := diviser / 2;
>       acc     := acc + 1;
>     end loop LogLoop;
>     return acc;
>   end function log2;
> end MATH;
>
>
>
>



Article: 26716
Subject: Re: implementing a memory
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Wed, 25 Oct 2000 23:46:18 +0200
Links: << >>  << T >>  << A >>


"Emanuele Russo" <emanuelerusso@tiscalinet.it> wrote in message
news:8t4r44$4rv$1@pegasus.tiscalinet.it...
> I'm a student and I've to synthetize a dual port memory in VHDL, but I've
> some problems with BUSes...
> ... can anyone help me with same example...
> thank you,
>
> Emanuele Russo
>
The enclosed VHDL will synthesize to the internal Dual port RAMs in
the Atmel AT40K series.


-- ********************************************************************
--   SYNCH DPRAM
-- ********************************************************************


-- HDLPlanner Start sdpram_prl
-- Do not **Delete** previous line
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
library WORK;
use WORK.all;
entity sdpram_prl is
-- synopsys template
 GENERIC (ADDR_WIDTH : INTEGER := 5;
   WIDTH : INTEGER := 4);
 port (
  Ain : in STD_LOGIC_VECTOR(ADDR_WIDTH-1 downto 0);
  Aout : in STD_LOGIC_VECTOR(ADDR_WIDTH-1 downto 0);
  Din : in STD_LOGIC_VECTOR(WIDTH-1 downto 0);
  Dout : out STD_LOGIC_VECTOR(WIDTH-1 downto 0);
  OEN : in STD_LOGIC;
  WEN : in STD_LOGIC;
  CLK : in STD_LOGIC
 );
end sdpram_prl;

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
library WORK;
use WORK.all;
architecture RTL of sdpram_prl is
constant clockEdge : STD_LOGIC := '1';
constant setOrResetLevel : STD_LOGIC := '0';
constant setOrReset : INTEGER := 0;


TYPE twoDarray is
 ARRAY(0 to 2**ADDR_WIDTH - 1) of STD_LOGIC_VECTOR(WIDTH-1 downto 0);
signal mem : twoDarray;
begin

dwrite: process (CLK,WEN,Ain)
variable write_address : INTEGER;
begin
 if (RISING_EDGE(CLK)) then
  write_address := CONV_INTEGER(Ain);
  if (WEN = '0') then
   mem(write_address) <= Din;
  end if;
 end if;
end process dwrite;


dread: process (OEN,Aout,mem)
variable read_address : INTEGER;
begin
 read_address := CONV_INTEGER(Aout);
 if (OEN = '0') then
  Dout <= mem(read_address);
 else
  for i in 0 to (WIDTH - 1) loop
   Dout(i) <= 'Z';
  end loop;
 end if;
end process dread;


end RTL;


-- ********************************************************************
--   ASYNCH DPRAM
-- ********************************************************************

library IEEE ;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
library WORK;
use WORK.all;
entity adpram_prl is
 generic (
  ADDR_WIDTH : INTEGER :=  5;
  WIDTH      : INTEGER :=  4
 );
 PORT (
  AIN       : in STD_LOGIC_VECTOR (ADDR_WIDTH-1 downto 0);
  AOUT      : in STD_LOGIC_VECTOR (ADDR_WIDTH-1 downto 0);
  DIN       : in STD_LOGIC_VECTOR (WIDTH-1 downto 0);
  DOUT      : OUT STD_LOGIC_VECTOR(WIDTH-1 downto 0);
  OEN       : in STD_LOGIC;
  WEN       : in STD_LOGIC
 );
end adpram_prl;

architecture behv of adpram_prl is

constant clockEdge : STD_LOGIC := '1';
constant setOrResetLevel : STD_LOGIC := '0';
constant setOrReset: integer := 0;

type twoDarray is
 array(0 to 2**ADDR_WIDTH - 1) of STD_LOGIC_VECTOR (WIDTH-1 downto 0);
signal mem : twoDarray ;
begin

dwrite: process (WEN,AIN,DIN)
variable write_address : INTEGER;
begin
 write_address :=  CONV_INTEGER(AIN);
 if(WEN = '0') then
  mem(write_address) <= DIN;
 end if;
end process dwrite;


dread: process (OEN,AOUT,mem)
variable read_address : INTEGER;
begin
 read_address :=  CONV_INTEGER(AOUT);
 if(OEN = '0') then
  DOUT <= mem(read_address);
 else
  for i in 0 to (WIDTH - 1) loop
   DOUT(i) <= 'Z';
  end loop;
 end if;
end process dread;
end behv;





--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden



Article: 26717
Subject: Re: ROC (reset on configuration) on Virtex ?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Oct 2000 22:30:29 GMT
Links: << >>  << T >>  << A >>
ROC is basically for simulation. Put it in your design to simulate the effect of
the reset on configuration.  If it is in the design, synplicity will black box
it into the edif netlist;  The alliance tools don't do anything with it though.  

You will find it in the unisim and simprim libraries.  The VHO output from the
ALliance tools will include it in the mapped (timing) VHDL output to get proper
simulation.

Muzaffer Kal wrote:
> 
> hi,
> I need an external reset and an internal power on reset type signal.
> In Synplicity libraries, there is a ROC cell for Virtex but there are
> no simulation libraries in Alliance toolset for ROC. Is this cell
> valid for Virtex ? I am also using a DLL. Is there a way to make sure
> that ROC doesn't go low before LOCK happens ? Also what is the timing
> for ROC signal after a configuration ?
> 
> thanks,
> 
> Muzaffer
> http://www.dspia.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 26718
Subject: New Web Hosting - $3.95 for 35Mb/CGI/Your Domain and 2Gb Monthly Traffic !!!
From: no.email.address.entered@none444.yet
Date: Wednesday, 25 Oct 2000 18:20:32 -0600
Links: << >>  << T >>  << A >>
USCOM offers full service virtual web hosting starting at only $3.95 month with high traffic, e-mail, FrontPage and Real Audio support, etc. We operate an 100mbps connection to the Internet which is more than 80 times a usual T-1 or 3 times larger than a regular T-3 connection.

Web Hosting Services :

http://www.uscom.tv

Sign up today and recive $15 Service Credit !


Article: 26719
Subject: Re: How safe is the algorithm implemented with FPGA?
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 25 Oct 2000 19:43:37 -0700
Links: << >>  << T >>  << A >>
On Wed, 25 Oct 2000 11:44:15 -0700, Brian Dipert wrote:
>Philip wrote:
>>I spoke to someone at Xilinx about this, and he confirmed that to the
>>extent of the article, what is disclosed is now public, and Brian Dipert
>>did not reveal stuff he shouldn't have under some NDA.
>
>Philip, Philip, Philip....you didn't think I was misbehaving, did you?
>;-)

Hardly. I already knew about this stuff (and more) under NDA, and
like most NDA's, they no longer cover material after it is made
publicly available (providing it wasnt made public through violating
my NDA). I just was checking the limits on what I can now talk
about to others. I have always trusted you  :-).

>Yes, my article marked the first public disclosure of Triple DES
>support in Virtex-II
>Brian Dipert

Evan wrote:
>I expect you're right. It does seem rather odd though - it was NDA'ed
>2 weeks ago and suddenly turns up in the press, which smells somewhat
>like a cock-up.

Or just part of the Virtex-II strip-tease. Full data sheets are not yet
publicly available, nor detailed CLB, BRAM, MPY, .....

I think we will continue to get snippets on capabilities up untill it
becomes available, maybe even beyond that.

With regard to your comments about what happens to the key on
battery failure, and having to send out the key to the customer,
I dont see the issue.

Either you trust the customers, in which case you dont need this
feature, or you dont trust them, in which case you will need the
board to be returned.

Several others have written:
> but I just open up the chip and read out the KEY.

Sure. Piece of cake. While I wont claim that this is impossible,
I believe you are wildly underestimating the difficulty of removing
a surface mount chip from a PCB, while keeping the battery
connected, and then opening the device up, and the fun you will
have trying to probe flipflops on the chip (where are they exactly),
especially with geometries that are sub-visible wave length. So
get out your handy SEM, and remember, keep that battery
attached.
(how did you do that for the BGA package part anyway?)
(how did you etch the epoxy (PQFP) while keeping the key alive?)
And when you have the key, and decrypt the bitstream, you still
just have a bitstream. Good enough to clone a design, not yet
a documented schematic/HDL :-)

Philip
Philip Freidin
Fliptronics

Article: 26720
Subject: Re: timing simulation with Xilinx and Fusion/SpeedWave
From: "Uwe" <u.clemens@fz-juelich.de>
Date: Thu, 26 Oct 2000 08:35:56 +0200
Links: << >>  << T >>  << A >>
Hallo Franz,

warum benutzt Du nicht IntelliFlow, der übernimmt i.A. alle Einstellungen
und Parameter. Bei mir funktioniert dieses ganz gut.

Gruß
  Uwe


"Franz Hollerer" <hollerer@hephy.oeaw.ac.at> schrieb im Newsbeitrag
news:39F57AF3.DACE8CD1@hephy.oeaw.ac.at...
> Hi,
>
> I have some questions about timing simulation and I hope
> that somebody can help me.
>
> The Xilinx software creates time_sim.vhd and time_sim.sdf.
> I now want to do a timing simulation with Fusion/SpeedWave.
> It principally works. But if I choose time_sim.sdf for further
> timing data, fusion prints a lot of error messages (see below).
>
> Do I really  need the .sdf file for a correct timing simulation or is
> the
> time_sim.vhd file enough?
>
> Any hints?
>
> Thanks
> Franz Hollerer
>
> -----------------------------------------------------------------------
> error message
> -----------------------------------------------------------------------
> Starting VITAL SDF Backannotation.
>   Processing SDF file: D:\hollerer\vhdl\tcs\export_dir\time_sim.sdf
>     Hierarchical Path Prefix:    /
>     Timing mode:                 Max
>     Hierarchy divider character: /
>     Timescale factor:            0.001 ns
> ** Error at SDF file line number 21:
> For this hierarchical path name in the SDF file:
>   '/PRE1_CNT_REG_0_Q'
> Could not find region level 'PRE1_CNT_REG_0_Q' in the VHDL design.
> ** Error at SDF file line number 22:
> For this hierarchical path name in the SDF file:
>   '/PRE1_CNT_REG_0_Q'
> Could not find region level 'PRE1_CNT_REG_0_Q' in the VHDL design.
> ** Error at SDF file line number 23:
> For this hierarchical path name in the SDF file:
>   '/PRE1_CNT_REG_0_Q'
> :
> :
> :
> and so on
>
> --
> Institut fuer Hochenergiephysik
> Nikolsdorfer Gasse 18
> 1050  Wien
> Austria
>
> Tel: (+43-1)5447328/50
>
>



Article: 26721
Subject: Fpga vs. ASIC
From: "korg" <korg_01@yahoo.de>
Date: 26 Oct 2000 08:33:01 GMT
Links: << >>  << T >>  << A >>
Hi there!

I would like to know where can I look for this topic and if you have some
tipps plz, tell me.

tx

korg

Article: 26722
Subject: Re: How safe is the algorithm implemented with FPGA?
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 26 Oct 2000 09:17:46 GMT
Links: << >>  << T >>  << A >>
On Wed, 25 Oct 2000 19:43:37 -0700, Philip Freidin
<philip@fliptronics.com> wrote:

>Several others have written:
>> but I just open up the chip and read out the KEY.
>
>Sure. Piece of cake. While I wont claim that this is impossible,
>I believe you are wildly underestimating the difficulty of removing
>a surface mount chip from a PCB, while keeping the battery
>connected, and then opening the device up, and the fun you will
>have trying to probe flipflops on the chip (where are they exactly),
>especially with geometries that are sub-visible wave length. So
>get out your handy SEM, and remember, keep that battery
>attached.
>(how did you do that for the BGA package part anyway?)
>(how did you etch the epoxy (PQFP) while keeping the key alive?)
>And when you have the key, and decrypt the bitstream, you still
>just have a bitstream. Good enough to clone a design, not yet
>a documented schematic/HDL :-)

I was at a seminar 2 or 3 years ago on pay TV security. The presenter
showed a slide of some guy's garage in Germany, with an electron
microscope in it. He'd got it second-hand for a few thousand dollars,
IIRC. He burned the top off a processor on a decoder card, attached
probes to a bus under the SEM, and reverse-engineered the security
algorithm on the chip. The info was then used to produce cloned
decoder cards.

Sure, a PCB with a battery-backed Virtex-II on it is going to be much
harder than this (I think), but I bet someone will be trying it as
soon as there's a commercial reason to do so.

Another aspect of this is that the goal may not actually be to
reverse-engineer the bitstream or find out what's in the chip. My
current problem is that I have encoded MPEG which I have to decode. As
soon as the pirate's found the clear MPEG, he can record it and he's
won. He's not going to have any interest whatever in the other stuff
I've got in the chip - any competent engineer could duplicate that
from scratch in a few weeks, if they even needed it to start with. I
suspect that a lot of FPGA security is like this - the engineer thinks
that it's his hard work that has to be protected, but the real secret
is something completely different, and is probably a lot less secure
than the FPGA bitstream.

Evan

Article: 26723
Subject: Re: How safe is the algorithm implemented with FPGA?
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 26 Oct 2000 09:18:20 GMT
Links: << >>  << T >>  << A >>
On 25 Oct 2000 20:25:39 GMT, nweaver@soda.CSUA.Berkeley.EDU (Nicholas
Weaver) wrote:

>	This model only requires that I hook up a battery to 2
>specific pins on the device, with no other external or internal logic
>required, yet it brings security ALMOST to the level of a battery
>backed up device with the configuration loaded/always on.

Yes, I agree - it's a lot more practical and may even be feasible in a
real product. But look at it from the customer's point of view. If
something does go wrong (sunspots? lightning? someone brings their
radioactive watch dial too close to the case? whatever..) then they
have to return the box to the manufacturer to get it fixed.

PC's used to (still have?) a battery-backed CMOS RAM. It hasn't
happened to me over the last few years, but I'm pretty sure that I've
had problems with the RAM being corrupted. I'm also pretty sure that I
wouldn't have bought the PC in the first place if it had to be shipped
back to the (possibly defunct) manufacturer to reload the CMOS.

Evan

Article: 26724
Subject: Re: Design theft story in EDN. New security ?
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 26 Oct 2000 09:18:45 GMT
Links: << >>  << T >>  << A >>
On Wed, 25 Oct 2000 11:50:03 -0700, Brian Dipert
<bdipert@NOSPAM.pacbell.net> wrote:

>'A lot' of discussion threads here find their way into my articles, as
>inspiration for topics if nothing else. After all, why waste my time
>writing on stuff that isn't of interest to y'all? ;-)

I look forward to the fully-documented traffic light controller design
feature, a subject close to everyone's heart here...

Evan 



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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