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 30300

Article: 30300
Subject: XCV1000BG560: onchip ram
From: sam <>
Date: Mon, 2 Apr 2001 02:45:11 -0800
Links: << >>  << T >>  << A >>
does anyone have an idea about the exact amount of onchip ram in a xilinx virtex XCV1000BG560.

sam

Article: 30301
Subject: Re: XCV1000BG560: onchip ram
From: krw@btv.ibm.com (Keith R. Williams)
Date: Mon, 02 Apr 2001 11:37:05 GMT
Links: << >>  << T >>  << A >>
On Mon, 2 Apr 2001 02:45:11 -0800, sam <> wrote:

>does anyone have an idea about the exact amount of onchip ram in a xilinx virtex XCV1000BG560.

My databook says 131,072 bits of BlockRAM and 393,218 bits of
SelectRam (Max).

----
  Keith


Article: 30302
Subject: pinout in text format for Virtex-E XCV200E
From: "Laurence McCotter" <mccotter@tality.com>
Date: Mon, 2 Apr 2001 13:31:04 +0100
Links: << >>  << T >>  << A >>
Can anyone help me out - I am looking for a pinout in text format for the
Virtex-E XCV200E-FG456 device. (or better still a symbol!!)
I plan to import the text file into ORCAD using the 'Generate Part' command
to create the symbol from the pin table file. I have asked 2 of Xilinx FAEs
by email  for this file last week and so far no reply!
Thanks





Article: 30303
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Mon, 02 Apr 2001 13:06:20 GMT
Links: << >>  << T >>  << A >>
There are no random sources inherent in the FPGA, although you could conceivably
use the phase difference between the internal oscillator in the 4Kparts and an
external clock.  I'd prefer to use the linear feedback shift register (LFSR)
with a long enough sequence to make it random over a long interval.  That can be
done very compactly in the 4K using CLB ram (see the xilinx app note on LFSRs, I
think it is XAPP152).  Use only one bit at a time from the LFSR though, the
other bits are time shifted copies of the first bit.  A 129 bit LFSR only takes
13 LUTs to implement and at 40 MHz will take thousands of years before it
repeats.  Of course at start-up it will start out with the same value, so the
sequence is always the same.  That is good for debug, but may be bad for your
system.  In that case, you need to seed the 129 bits with a random value on
startup (if you seed it serially, the LFSR is still the same size).  The random
seed has to be generated by something external to the FPGA since the FPGA is
always the same on startup.  One possibility, which I mentioned above is to use
the random relationship of the internal oscillator and an external clock to seed
the LFSR. 

 I'd use the internal oscillator phase relationship to seed an LFSR rather than
directly for two reasons: 1) The instantaneous phase relationship will be
random, but a time series will be periodic, and 2) non-repeatability of the
phase makes debug difficult.  (The LFSR can be forced to a particular start
state for debug).

Jörg Ritter wrote:
> 
> Hello,
> 
> has someone expierience with generating (pseudo) random numbers in
> FPGA's (XC4000XLA series) ?
> 
> My first idea was to use maximal length sequences (shift registers
> having maximum possible period for an r-stage shift register)
> 
> Is there another source of randomness of the FPGA istself which can be
> used ?
> 
> thanks
> Joerg

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

Article: 30304
Subject: Re: adding std_logic_vectors
From: Ray Andraka <ray@andraka.com>
Date: Mon, 02 Apr 2001 13:12:04 GMT
Links: << >>  << T >>  << A >>
use ieee.numeric_std.all instead

c<=std_logic_vector( resize( unsigned(A) + unsigned(B) , c'length));

numeric_std is more cohesive, and although you need to be specifc for signed and
unsigned types, ther are no conflicts if you need both.  the std_logic libraries
overload the same operators for signed and unsigned so mixing them can get
unexpected results.



Matt Billenstein wrote:
> 
> All,
> 
> I'm using synopsys with the Xilinx Foundation tools (3.3i I believe) and I'm
> seeing some strange behavior with a particular construct...
> 
> I include IEEE.std_logic_unsigned.all so that I can add std_logic_vectors.
> When I do something like:
> 
> SIGNAL
>   A, B : std_logic_vector(7 downto 0);
> 
> SIGNAL C : std_logic_vector(8 downto 0);
> 
> and then later in the architecture in a registered process:
> 
> C <= ('0' & A) + ('0' & B);
> 
> I include the '0' here on vectors A and B so that the types on the LHS and
> RHS are the same (9 bit vectors), but the synthesis tool appears to trim off
> the top bit of the C vector...  Thus, if I add a couple numbers like
> 10000001 and 10000001 I should get 100000010 (which is 9 bits), but I only
> get 00000010 (which is 8 bits)...  I lose the MSb.  It turns out that on the
> very next clock cycle I subtract a constant bias (decimal 127) from C so I
> never actually use the 8th bit of the C vector for any output.  I could code
> it differently to take the bias out of either vector A or B before I add
> them, but it appears the synthesis tool isn't actually giving me what I
> asked for...  Any ideas?
> 
> thx
> 
> Matt
> 
> --
> 
> Matt Billenstein
> mbillens (at) one (dot) net
> http://w3.one.net/~mbillens/

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

Article: 30305
Subject: some info. on FPGA
From: "hanshu" <hanshu@arch.cs.pku.edu.cn>
Date: Mon, 2 Apr 2001 21:23:13 +0800
Links: << >>  << T >>  << A >>
Hello everyone

I need some information on the basic introduction of FPGA.Please give me
some advise .




Article: 30306
Subject: Re: pseudo random numbers
From: =?iso-8859-1?Q?J=F6rg?= Ritter <ritter@informatik.uni-halle.de>
Date: Mon, 02 Apr 2001 15:26:43 +0200
Links: << >>  << T >>  << A >>
Hello Ray,

> There are no random sources inherent in the FPGA, although you could co=
nceivably
> use the phase difference between the internal oscillator in the 4Kparts=
 and an
> external clock.

this is what I was looking for.
Thanks for your detailed answer, especially for the 4k implementation met=
hod's.

ciao
J=F6rg



Article: 30307
Subject: Re: pseudo random numbers
From: "Eric Pearson" <ecp@mgl.ca>
Date: Mon, 2 Apr 2001 09:27:57 -0400
Links: << >>  << T >>  << A >>
Hello Joerg...

I've been looking into the same thing. Here's a clear paper with
good coverage and references.

http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf

As to other forms of built in randomness...

I think that metastability and propagation delay are two factors avaliable
which
have some randomness to them. If a oscillator were made (3 inverters), then
build a random number by sampling this output at a widely space interval,
there should
be a degree of randomness.

The key problem would be guaranteed startup of the oscillator (help!), else
the number
wouldn't be very random.

Eric Pearson
Carde Systems
Waterloo, Ontario
YAFC


Jörg Ritter <ritter@informatik.uni-halle.de> wrote in message
news:3AC850A3.6E2A36B@informatik.uni-halle.de...
> Hello,
>
> has someone expierience with generating (pseudo) random numbers in
> FPGA's (XC4000XLA series) ?
>
> My first idea was to use maximal length sequences (shift registers
> having maximum possible period for an r-stage shift register)
>
> Is there another source of randomness of the FPGA istself which can be
> used ?
>
> thanks
> Joerg
>



Article: 30308
Subject: Re: pseudo random numbers
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Mon, 02 Apr 2001 15:33:13 +0200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
[...]
> Use only one bit at a time from the LFSR though, the other bits
> are time shifted copies of the first bit.

What about shuffling the bits? Or using only some bits from a large
LFSR?
Just a thought but I find it interesting...
-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/

Article: 30309
Subject: good knwoledge in fpga or vhdl
From: christopheguelff@aol.com (ChristopheGuelff)
Date: 02 Apr 2001 14:32:03 GMT
Links: << >>  << T >>  << A >>
Hi all

We are actually working an a openhardware/opensource computer. If you have a
good knwoledge in FPGA or VHDL, you can join us ! If you want to learn how to
build your own eZ80 computer, too !

Our web site is http://cpcng.free.fr


Article: 30310
Subject: Re: pinout in text format for Virtex-E XCV200E
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Mon, 02 Apr 2001 15:55:50 +0100
Links: << >>  << T >>  << A >>
On Mon, 2 Apr 2001 13:31:04 +0100, "Laurence McCotter"
<mccotter@tality.com> wrote:

>Can anyone help me out - I am looking for a pinout in text format for the
>Virtex-E XCV200E-FG456 device. (or better still a symbol!!)
>I plan to import the text file into ORCAD using the 'Generate Part' command
>to create the symbol from the pin table file. I have asked 2 of Xilinx FAEs
>by email  for this file last week and so far no reply!
>Thanks
>
If you can't find a better way, there is such a thing in the BSDL files
in xilinx\virtexe\data\*.bsd

- Brian



Article: 30311
Subject: Re: Anadigms FPAA
From: "ajd" <ajadu76@hotmail.com>
Date: Mon, 2 Apr 2001 16:18:40 +0100
Links: << >>  << T >>  << A >>
try emailing mailto:info@anadigm.com They're bound to have a support desk.

"Fredrik Theander" <fredrik.theander@mbox301.swipnet.se> wrote in message
news:Oq5x6.1768$e04.5422@nntpserver.swip.net...
> Hi
>
> My name is Fredrik Theander I'm working on my exam thesis. My topic is
> programmable analog devices I currently evaluating Anadgims FPAA. I wonder
> if anyone have had any experience with it?
> I would be glad to find someone who i can swap ideas with.
>
> regards
> Fredrik Theander
>
>



Article: 30312
Subject: Re: adding std_logic_vectors
From: Reto Zimmermann <reto@synopsys.com>
Date: Mon, 02 Apr 2001 10:06:52 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> c<=std_logic_vector( resize( unsigned(A) + unsigned(B) , c'length));

This does not yield the correct MSB (a potential carry-out is dropped
before the resizing).  Try

C <= std_logic_vector (resize (unsigned (A), C'length) +
                       resize (unsigned (B), C'length));

instead.

Reto

Article: 30313
Subject: Re: xapp258 question
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 02 Apr 2001 09:49:10 -0800
Links: << >>  << T >>  << A >>


yorams@hywire.com wrote:

>  Hi.
> I have read xilinx application note xapp258 and I have the following
> question:
>
> <snip>
> the following might occur
>
> path between bit i of counter to its synchronizer is: epsilon;
> path between bit j of counter to its synchronizer is: epsilon + Tcyc;
>
> under these condition the synchronizer can sample false value of the gray
> counter and thus give false full or empty flag.
>
>
> Is it possible ?
> Can it be avoided ?
>

The idea behind using Grey counters is that they make the problem you mention
disappear.
If you transfer the Grey value from one clock domain to the other, and you do it
at the most awkward moment, right as the Grey counter increments, you will not
transfer garbage ( which might happen with a binary counter ), since adjacent Grey
values only differ by one bit. So you transfer either the old or the new value.
Either one is as good as the other at that particular moment.

Peter Alfke, Xilinx Applications


Article: 30314
Subject: Re: FPGA V CPLD
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Mon, 02 Apr 2001 11:17:11 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Simon Bacon wrote:
> 
> >
> > OTOH, you may be claiming that the band of brothers who work on
> > FPGA designs are a tempermental bunch...
> 
> No Simon you must not give the guy the wrong impression. We are of course
> calm, rational, gentle citizens of the digital world who help people
> across the road and are very kind to all fellow creatures of this lovely
> planet. We only become temperamental, irrational, demented scary monster
> types when faced with:
> 
> o The imminent arrival of the design which we have been working on for
> months,
> 
> o The cancellation of the project ditto,
> 
> o The sudden non-availability of parts we have designed into ditto,
> 
> o The appearence on this NG of opinions contrary to our most deeply held
> beliefs,
> 
> ...
> 
> o Yet another MAP/PAR bug.

Or synthesis bug.

-andy

Article: 30315
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Mon, 02 Apr 2001 19:06:47 GMT
Links: << >>  << T >>  << A >>


Nicolas Matringe wrote:
> 
> Ray Andraka wrote:
> [...]
> > Use only one bit at a time from the LFSR though, the other bits
> > are time shifted copies of the first bit.
> 
> What about shuffling the bits? Or using only some bits from a large
> LFSR?
> Just a thought but I find it interesting...

The problem with using more than one bit from an LFSR is that all the other bits
are related by time (they are just time shifted copies), therefore, even if you
space the selected bits out and/or shuffle them, you still get spectral coloring
in your random number.  The one way around that is to space the bits far enough
apart that the correlation is not a factor within your sample interval.  That,
however requires a large number of bit delays, at which point it is usually more
economical to use multiple LFSRs that are identical except the seeds (and the
seeds are spaced far apart). Another solution involves clocking the LFSR n times
to generate an n bit random value using successive outputs.

 For some applications, such as memory testing, the spectral coloring may not be
a factor, so less care is needed.  If you are trying to model noise however,
then you'll want to be careful about correlations between bits.


> --
> Nicolas MATRINGE           IPricot European Headquarters
> Conception electronique    10-12 Avenue de Verdun
> Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
> Fax +33 1 46 52 53 01      http://www.IPricot.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

Article: 30316
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Mon, 02 Apr 2001 19:14:59 GMT
Links: << >>  << T >>  << A >>


Eric Pearson wrote:
> 
> Hello Joerg...
> 
> I've been looking into the same thing. Here's a clear paper with
> good coverage and references.
> 
> http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf
> 
> As to other forms of built in randomness...
> 
> I think that metastability and propagation delay are two factors avaliable
> which
> have some randomness to them.

You might have a very difficult time hitting the metastability in an FPGA.  The
window is very small, and the only time you can seem to hit it consistently is
when you don't want to :-(

For sampling an oscillator, I mentioned before that if both your system clock
and your oscillator are reasonably stable, then the results of sampling will be
periodic. (the sum of a finite set of periodic signals is also periodic).  You
lose the random distribution.  Also worth noting, is it seems an ring oscillator
implemented in the FPGA might tend to lock to a system clock because of the
changes in local supply voltage due to currents drawn on the clock edges
elsewhere in the FPGA.  These two reasons are why I suggested using the phase
difference between an oscillator and the system clock just once on start-up to
initialize an LFSR rather than attempting to use it all the time.


 If a oscillator were made (3 inverters), then
> build a random number by sampling this output at a widely space interval,
> there should
> be a degree of randomness.
> 
> The key problem would be guaranteed startup of the oscillator (help!), else
> the number
> wouldn't be very random.
> 
> Eric Pearson
> Carde Systems
> Waterloo, Ontario
> YAFC
> 
> Jörg Ritter <ritter@informatik.uni-halle.de> wrote in message
> news:3AC850A3.6E2A36B@informatik.uni-halle.de...
> > Hello,
> >
> > has someone expierience with generating (pseudo) random numbers in
> > FPGA's (XC4000XLA series) ?
> >
> > My first idea was to use maximal length sequences (shift registers
> > having maximum possible period for an r-stage shift register)
> >
> > Is there another source of randomness of the FPGA istself which can be
> > used ?
> >
> > thanks
> > Joerg
> >

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

Article: 30317
Subject: Re: FPGA V CPLD
From: "Speedy Zero Two" <dlatter@manorsNOSPAMway.freeserve.co.uk>
Date: Mon, 2 Apr 2001 22:00:28 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_0044_01C0BBC0.540802E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

  Austin,=20

  SNIP=20

  I also decided to use an FPGA for a fiber optic framer/codec.  When we =
had shipped the 10,000th unit, the customer came back and said "it won't =
send all 0's." [ I kid you not.]  All 0's is what the customer (secret =
governement user) wanted to send.  All day, all night.  They needed to =
know that the n-th 0 was really the n-th 0, and not the n-th plus 1 "0". =
 It seems that the codec saw all 0's, and substituted a keep alive code =
instead.  For some unknown reason, every 0 in its proper place and order =
was critically important to the national security!  They told me it was =
encrypted.  Wow, some encryption algorithm!=20

  SNIP=20

  =20

  I believe that there are a couple of very good compression techniques =
which can reduce a file from an infinite length down to a single bit.=20

  These are so secret that if anybody found out then you would have a =
national emergency.=20

  Maybe your FPGA was used in this form of encryption.=20

  I have heard it also rumored that the British hoofed animals got wind =
of this and the government is secretly trying to cover it up.=20

  Seriously though, Thanks all for your help =20

  Dave


------=_NextPart_000_0044_01C0BBC0.540802E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3017.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <P><FONT face=3DArial size=3D2>Austin,</FONT>=20
  <P><FONT face=3DArial size=3D2>SNIP</FONT>=20
  <P>I also decided to use an FPGA for a fiber optic framer/codec.&nbsp; =
When we=20
  had shipped the 10,000th unit, the customer came back and said "it =
won't send=20
  all 0's." <B>[ I kid you not.]</B>&nbsp; All 0's is what the customer =
(secret=20
  governement user) wanted to send.&nbsp; All day, all night.&nbsp; They =
needed=20
  to know that the n-th 0 was really the n-th 0, and not the n-th plus 1 =

  "0".&nbsp; It seems that the codec saw all 0's, and substituted a keep =
alive=20
  code instead.&nbsp; For some unknown reason, every 0 in its proper =
place and=20
  order was critically important to the national security!&nbsp; They =
told me it=20
  was encrypted.&nbsp; Wow, some encryption algorithm!=20
  <P>SNIP=20
  <P>=20
  <P>I&nbsp;believe that there are a couple of very good compression =
techniques=20
  which can reduce a file from&nbsp;an infinite length down to a single =
bit.=20
  <P>These are so secret that if anybody found out then you would have a =

  national emergency.=20
  <P>Maybe&nbsp;your FPGA was used in this form of encryption.=20
  <P><FONT face=3DArial size=3D2>I have heard it also rumored that the=20
  British&nbsp;hoofed animals got wind of this and the&nbsp;government =
is=20
  secretly trying to cover it up.</FONT>=20
  <P><FONT face=3DArial size=3D2>Seriously though, Thanks all =
for&nbsp;your=20
  help</FONT>&nbsp;=20
  <P><FONT face=3DArial =
size=3D2>Dave</FONT></P></BLOCKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_0044_01C0BBC0.540802E0--


Article: 30318
Subject: accepted papers at CHES 2001
From: Christof Paar <christof@ece.wpi.edu>
Date: Mon, 2 Apr 2001 17:01:38 -0400
Links: << >>  << T >>  << A >>

Workshop on Cryptographic Hardware and Embedded Systems
  Espace Saint Martin, Paris, France, May 13-16, 2001
     
           http://www.chesworkshop.org

for registration information, check CHES web site above
-------------------------------------------------------
		
		INVITED SPEAKERS

Ross Anderson, University of Cambridge, U.K.
   Protecting Embedded Systems - the Next Ten Years.

Adi Shamir, Weizmann Institute, Israel.
   TBA 
-------------------------------------------------------
      
	  LIST OF ACCEPTED PAPERS FOR CHES 2001

      (contributions are ordered by date submitted)


Leone Manuel.
A new low complexity fast parallel multiplier for a
class of finite fields.

Pierre-Yvan Liardet and Nigel Smart.
Preventing SPA/DPA in ECC systems using the Jacobi form.

Mike Bond.
Attacks on cryptoprocessor transaction sets.

Louis Goubin.
A sound method for switching between boolean and
arithmetic masking.

Helena Handschuh and Christophe Tymen.
Fast primitives for internal data scrambling in tamper
resistant hardware.

Marc Joye and Christophe Tymen.
Protections against differential analysis for elliptic
curve cryptography: An algebraic approach.

Adam Young and Moti Yung.
Bandwidth-optimal kleptographic attacks.

Nigel Smart.
The Hessian form of an elliptic curve.

Mehdi-Laurent Akkar and Christophe Giraud.
An implementation of DES and AES, secure against some
attacks.

Palash Sarkar and Subhamoy Maitra.
Efficient implementation of large stream cipher systems.

Karine Gandolfi, Christophe Mourtel, and Francis Olivier.
Electromagnetic analysis: Concrete results

Ocean Cheung, K. H. Tsoi, Philip Leong, and Norris Leong.
Tradeoffs in parallel and serial implementations of the
International Data Encryption Algorithm IDEA.

Thomas Pornin.
Transparent harddisk encryption.

Erkay Savas, Tom Schmidt, and Cetin K. Koc.
Generating elliptic curves of known order.

Hanae Nozaki, Masahiko Motoyama, Atsushi Shimbo, and
Shinichi Kawamura.
Implementation of RSA Algorithm based on RNS Montgomery
Multiplication.

Colin Walter.
Sliding windows succumbs to big mac attack.

Manfred Aigner and Elisabeth Oswald.
Randomized addition-subtraction chains as a countermeasure
against power attacks.

Maire McLoone and J. V. McCanny.
High performance single-chip FPGA Rijndael algorithm
implementations.

Katsuyuki Okeya and Kouichi Sakurai.
Efficient elliptic curve cryptosystems from a scalar
multiplication algorithm with recovering y-coordinate
on the Montgomery-form.

D. May, H. L. Muller, and Nigel Smart.
Random register renaming to foil DPA.

Viktor Fischer and Milos Drutarovsky.
Two methods of Rijndael implementation in reconfigurable
Hardware.

Christophe Clavier and Marc Joye.
Universal exponentiation algorithm: A first step towards
provable SPA-resistance.

Pradeep Dubey, Vijay Kumar, Atri Rudra, Charanjit Jutla,
Josyula R. Rao, and Pankaj Rohatgi.
Efficient implementations of Galois field arithmetic.

Henry Kuo and Ingrid Verbauwhede.
Architectural optimization for a 3Gbits/sec VLSI
Implementation of the AES Rijndael algorithm.

Nick Howgrave-Graham, Joan Dyer, and Rosario Gennaro.
Pseudo-random number generation on the IBM 4758 secure
crypto coprocessor.

Johann Groszschaedl.
A bit-serial unified multiplier architecture for finite
fields GF(p) and GF(2^m).

Gerardo Orlando and Christof Paar.
A scalable GF(p) elliptic curve processor architecture
for programmable hardware.

Marc Joye and Jean-Jacques Quisquater.
Hessian elliptic curves and side-channel attacks.

Werner Schindler.
Efficient online tests for true random number generators.

Alexandre F. Tenca, Georgi Todorov, and Cetin K. Koc.
High-radix design of a scalable modular multiplier.

Daniel V. Bailey, Daniel Coffin, Adam Elbirt, 
Joseph H. Silverman, and Adam D.  Woodbury.
NTRU in Constrained Devices.

-------------------------------------------------------
Workshop on Cryptographic Hardware and Embedded Systems
Web:            http://www.chesworkshop.org
E-Mail:         ches@ece.orst.edu
Program Chairs: Cetin Kaya Koc <koc@ece.orst.edu>
                David Naccache <David.Naccache@gemplus.com>
                Christof Paar <christof@ece.wpi.edu>
-------------------------------------------------------



Article: 30319
Subject: Re: FPGA V CPLD
From: "Speedy Zero Two" <dlatter@manorsNOSPAMway.freeserve.co.uk>
Date: Mon, 2 Apr 2001 22:04:02 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C0BBC0.D3A51420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

  Austin,=20

  SNIP=20

  I also decided to use an FPGA for a fiber optic framer/codec.  When we =
had shipped the 10,000th unit, the customer came back and said "it won't =
send all 0's." [ I kid you not.]  All 0's is what the customer (secret =
governement user) wanted to send.  All day, all night.  They needed to =
know that the n-th 0 was really the n-th 0, and not the n-th plus 1 "0". =
 It seems that the codec saw all 0's, and substituted a keep alive code =
instead.  For some unknown reason, every 0 in its proper place and order =
was critically important to the national security!  They told me it was =
encrypted.  Wow, some encryption algorithm!=20

  SNIP=20


  I believe that there are a couple of very good compression techniques =
which can reduce a file from an infinite length down to a single bit.=20

  These are so secret that if anybody found out then you would have a =
national emergency.=20

  Maybe your FPGA was used in this form of encryption.=20

  I have heard it also rumored that the British hoofed animals got wind =
of this and the government is secretly trying to cover it up.=20

  Seriously though, Thanks all for your help =20

  Dave


------=_NextPart_000_004E_01C0BBC0.D3A51420
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3017.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <P><FONT face=3DArial size=3D2>Austin,</FONT>=20
  <P><FONT face=3DArial size=3D2>SNIP</FONT>=20
  <P>I also decided to use an FPGA for a fiber optic framer/codec.&nbsp; =
When we=20
  had shipped the 10,000th unit, the customer came back and said "it =
won't send=20
  all 0's." <B>[ I kid you not.]</B>&nbsp; All 0's is what the customer =
(secret=20
  governement user) wanted to send.&nbsp; All day, all night.&nbsp; They =
needed=20
  to know that the n-th 0 was really the n-th 0, and not the n-th plus 1 =

  "0".&nbsp; It seems that the codec saw all 0's, and substituted a keep =
alive=20
  code instead.&nbsp; For some unknown reason, every 0 in its proper =
place and=20
  order was critically important to the national security!&nbsp; They =
told me it=20
  was encrypted.&nbsp; Wow, some encryption algorithm!=20
  <P>SNIP=20
  <P>
  <P>I&nbsp;believe that there are a couple of very good compression =
techniques=20
  which can reduce a file from&nbsp;an infinite length down to a single =
bit.=20
  <P>These are so secret that if anybody found out then you would have a =

  national emergency.=20
  <P>Maybe&nbsp;your FPGA was used in this form of encryption.=20
  <P><FONT face=3DArial size=3D2>I have heard it also rumored that the=20
  British&nbsp;hoofed animals got wind of this and the&nbsp;government =
is=20
  secretly trying to cover it up.</FONT>=20
  <P><FONT face=3DArial size=3D2>Seriously though, Thanks all =
for&nbsp;your=20
  help</FONT>&nbsp;=20
  <P><FONT face=3DArial =
size=3D2>Dave</FONT></P></BLOCKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_004E_01C0BBC0.D3A51420--


Article: 30320
Subject: Re: pseudo random numbers
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 03 Apr 2001 09:06:17 +1200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Eric Pearson wrote:
> >
> > Hello Joerg...
> >
> > I've been looking into the same thing. Here's a clear paper with
> > good coverage and references.
> >
> > http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf
> >
> > As to other forms of built in randomness...
> >
> > I think that metastability and propagation delay are two factors avaliable
> > which
> > have some randomness to them.
> 
> You might have a very difficult time hitting the metastability in an FPGA.  The
> window is very small, and the only time you can seem to hit it consistently is
> when you don't want to :-(
> 
> For sampling an oscillator, I mentioned before that if both your system clock
> and your oscillator are reasonably stable, then the results of sampling will be
> periodic. (the sum of a finite set of periodic signals is also periodic).  You
> lose the random distribution.  Also worth noting, is it seems an ring oscillator
> implemented in the FPGA might tend to lock to a system clock because of the
> changes in local supply voltage due to currents drawn on the clock edges
> elsewhere in the FPGA.

 Certainly true. The common mode layout inductances, plus CMOS currents
combine to make
very good 'lock' systems for simple oscillators.  
 This lock band will be highly Vcc/Temp/Process dependant, as the simple
osc sweeps.

 By using a LFSR, and a dynamically tapped delay line ( series of gates
) you could
deliberately wobble the osc about, and thus reduce the chances of
staying on
a lock-point.

Jim G.

Article: 30321
Subject: Re: FPGA V CPLD
From: "Victor Schutte" <victors@mweb.co.za>
Date: Mon, 2 Apr 2001 23:14:15 +0200
Links: << >>  << T >>  << A >>

"Simon Bacon" <simonb@tile.demon.co.cut_this.uk> wrote in message
news:985907702.2172.0.nnrp-09.9e9832fa@news.demon.co.uk...
>

> OTOH, you may be claiming that the band of brothers who work on
> FPGA designs are a tempermental bunch...

Might be, you know...  Most of the FPGA designers I know feel insulted if
they have to work in a machine with less than 1Gig of RAM.



Article: 30322
Subject: Re: Books for trade
From: "Compilit" <compilehr@hotmail.com>
Date: Mon, 2 Apr 2001 14:57:49 -0700
Links: << >>  << T >>  << A >>
Hell Everyone,

I am currently negotiating with vj_sananda@hotmail.com of New Hampshire to
trade my two books Computer Architecture and Timing Verification for his
Janick Bergeron's Writing test benches.

Thanks.


Looking for recommendations on Computer Arithmetics books.

Thanks.

"Compilit" <compilehr@yahoo.com> wrote in message
news:99u33j$f7l$1@taliesin.netcom.net.uk...
> I have some EE books for trade. I am in the San Francisco Area.
>
> These all are all in brand new, unnused condition. Some have CD-ROM's
> included that are not yet opened.
> I bought them for a project now currently on hold.
>
> Please search www.abebooks.com or www.powells.com or www.Amazon.com for
good
> deals on these, and get back to me. Please help me to get the books I
need.
>
> The following list are what I currently have extra to be given away:
>
> 1/ Designer's Guide to VHDL by Peter Ashenden
>
http://www.amazon.com/exec/obidos/ASIN/1558602704/qid=985827963/sr=1-3/ref=s
> c_b_4/002-1116465-7214451
> 2/ VHDL Analysis and Modeling of Digital systems 2ed by Navabi
>
> 3/ Computer Architechiture, and Quantitative Approach.
>
> 4/ Verilog Digital Computer Design. Algorithms into Hardware by Arnold
>
> 5/ Real World FPGA Design with Verilog by Ken Coffman
>
> 6/ VHDL Representation and Synthesis by Armstrong and Gary
>
> 7/ VHDL made easy by Tellering and Taylor
>
> 8/ Verilog HDL by Palnitkar
>
> 9/ Verilog Designer's Library by Zeidman
>
> 10/ Timing Verification (ASIC) by Farzd Nekoogar
>
http://www.amazon.com/exec/obidos/ASIN/0137943482/ref=sim_books/002-1116465-
> 7214451
>
> 11/ VHDL by Douglas Perry
>
> 12/ VHDL for programmable logic by Kevin Skahill
>
> 13/ Real Time Signal Processing John G. Ackenhusen
>
http://www.amazon.com/exec/obidos/ASIN/0136317715/qid=985827868/sr=1-2/ref=s
> c_b_3/002-1116465-7214451
>
> 14/ Object Oriented Perl by Conway
>
> 15/ Programming and Customizing PIC controller Predro
>
> 16/ PCI-X System Architecture Mindshare INC
>
> 17/ Application-Specific Integrated Circuits. By Smith
>
> 18/ VHDL for Logic Synthesis by Andrew Rushton
>  http://www.amazon.com/exec/obidos/search-handle-form/002-1116465-7214451
>
> =====================================================================
>
>
> The following are what I am in desparate need for, I don't mind them in
used
> conditions:
>
> 1/
>
http://www.amazon.com/exec/obidos/ASIN/0792377664/ref=ase_janickbergershom/0
> 02-1116465-7214451
> Writing Testbenches - Functional Verification of HDL Models
> by Janick Bergeron
>
> 2/ System-on-a-Chip Verification - Methodology and Techniques
>
http://www.amazon.com/exec/obidos/ASIN/0792372794/qid=985827145/sr=1-4/ref=s
> c_b_5/002-1116465-7214451
>
>
> 3/ Rajsuman, Rochit SYSTEM ON A CHIP DESIGN AND TEST
> http://dogbert.abebooks.com/abe/BookDetails?bi=75782617
>
> 4/Keating, Michael and Pierre Bricaud Reuse Methodology Manual For
> System-On-A-Chip Designs
> http://dogbert.abebooks.com/abe/BookDetails?bi=53348445
>
> 5/HDL chip design :a practical guide for designing, synthesizing, and
> simulating ASICs and FPGAs using VHDL or Verilog
>
> http://www.powells.com/cgi-bin/biblio?inkey=2-0965193438-0
>
> 6/PRINCIPLES OF VERILOG PLI
> by Swapnajit Mittra
> http://www.powells.com/cgi-bin/biblio?inkey=4-0792384776-0
>
> 7/VHDL Coding and Logic Synthesis with Synopsys by Weng Fook Lee
>
http://www.amazon.com/exec/obidos/ASIN/0124406513/qid=985827963/sr=1-6/ref=s
> c_b_7/002-1116465-7214451
>
> 8/Vhdl Coding Styles and Methodologies by Ben Cohen must be 2nd edition
> http://dogbert.abebooks.com/abe/BookDetails?bi=52919198
>
> 9/Cohen, Ben VHDL ANSWERS TO FREQUENTLY ASKED QUESTION 2nd edition
> http://dogbert.abebooks.com/abe/BookDetails?bi=55220448
>
> 10/Component Design by Example : a Step-by-Step Process Using VHDL with
UART
> as Vehicle
> by Ben Cohen
>
> Thank you,
> Peace.
>
> Please click reply to email me.
>
>



Article: 30323
Subject: Re: Reed/Solomon ENcoder
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 02 Apr 2001 15:32:00 -0700
Links: << >>  << T >>  << A >>
Meloun <meloun@miracle.cz> writes:
> Near simple problem :-)

Thanks for posting the RS encoder.  I might find that useful in the future.
The original request (by someone else) was just for the encoder, but is
there any chance that you have a decoder to share as well?

Best regards,
Eric

Article: 30324
Subject: Re: Dist_ram :Memory instantiation
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 03 Apr 2001 00:18:23 +0100
Links: << >>  << T >>  << A >>


prashanth wrote:

> Hallo sir.
> How to use the distributed ram in VERTEX_E for instantiation of memory

If you have a decent synth tool try this:

reg [M:0] rdaddr, wraddr;

reg [N:0] ram [2**M:0];

    always @(posedge clk)
        if (we)
            ram[wraddr] <= din;

    assign dout = ram[rdaddr];

OTOH If you have FPGA Express then you'll have to use CoreGen.




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