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 86500

Article: 86500
Subject: Re: Small FPGA
From: Sylvain Munaut <com.246tNt@tnt>
Date: Wed, 29 Jun 2005 12:39:16 +0200
Links: << >>  << T >>  << A >>

Hi Antti,

> 
> 
> if in hurry then you must either use TQFP100 package or BGA


Finally I think I wont use PLD at all.
A RC filter for "quick & dirty" pre-debounce and a simple 8bit µC
to handle to rest of the logic will do. It doesn't need to be very
fast anyway.


	Sylvain

Article: 86501
Subject: Re: Small FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 29 Jun 2005 12:43:08 +0200
Links: << >>  << T >>  << A >>
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
news:42c27a2c$0$29635$ba620e4c@news.skynet.be...
>
> Hi Antti,
>
> >
> >
> > if in hurry then you must either use TQFP100 package or BGA
>
>
> Finally I think I wont use PLD at all.
> A RC filter for "quick & dirty" pre-debounce and a simple 8bit µC
> to handle to rest of the logic will do. It doesn't need to be very
> fast anyway.
>
>
> Sylvain

HAHA, that is good optimization!!!! from 500LE down to 0!
with proper firmware you may not need the external debounce but it all
depends sometime the rc network is good choice

sure if there is no direct need for high speed logic then small flash micro
is better choice.

my current favorite is ATmega8 in QFN32 package, but thats all a matter of
taste

Antti



Article: 86502
Subject: Re: proth siever in FPGA? [LONG]
From: "Alex" <alex@greenbank.org>
Date: 29 Jun 2005 03:53:05 -0700
Links: << >>  << T >>  << A >>
Thanks for the comments (Andrew & JJ). Let me explain a bit.
You asked for this! :-)

I don't need an FFT because I don't need to multiply numbers.
The sieving can be performed on 'small' integers (64-bits
gives a very large scope) using addition, subtraction, left
shifting by one bit and comparisons.

No multiplication and no floating-point makes it much
easier.

Proth sieving has some unique characteristics that make it
different from the Mersenne primes research.

The main goal is to maximise numbers sieved based on time.
This splits into two seperate goals:-
- Maximising the speed of each individual siever.
- Maximising the number of sievers on the FPGA.

Obviously pipelining may be required to complete one
iteration of the loop within one clock cycle, but then that
may increase the number of slices used by each siever,
bringing down the number of sievers that I can place on the
FPGA.

I'm playing around with a Spartan-3 starter kit as that is
the only platform I have for development. This is a hobby
project (not University project), if I can get reasonable
performance then I may consider moving up to a larger FPGA
with more gates (to get more sievers).

I'll only ever be working with dev kits. I don't intend
(unless the performance is stunning) that I'd ever consider
to build anything with multiple FPGAs, although my inner-geek
would love to have a box with lots of blinkenlights and
serious amounts of processing power.

The 50MHz comment was purely my brain not working. I had
glanced at the description and the mentioning of a 50MHz
oscillator had stuck in my brain. I then assumed that the
final solution would be limited to 50MHz. I've no idea
how quick an XC3S200 can actually run, or would run with
this 'design'. (could anyone give a rough guess?)

As for the actual problem I want to solve, here's a 'quick'
description of Proth sieving and why I want to do it.

Proth numbers are numbers of the form k*2^n+1 where
2^n > k. k should be odd (for obvious reasons).

A Sierpinski number (of the second kind) is a value of k
so that k*2^n+1 is composite for all k.

k=78557 will always produce composite numbers for any
positive n you pick. This has been proven.

To prove that a k is not a Sierpinski number one must find a
value for n such that k*2^n+1 produces a prime number.

The Sierpinski conjecture is that 78557 is the lowest value
of k possible. Of the 39278 other odd candidates, primes
have been found for all but 9.

The conjecture is regarded as true by most people and so
primes for the other 9 k-values are expected to be found.

There's more on the Sierpinski problem here:-
    http://www.seventeenorbust.com/
(That URL looks a bit suspect but trust me on this. There
used to be 17 candidate k-values but the above project has
found primes for 8 of them.)

The above site is running a distributed attack (a la SETI,
Cancer@Home, etc) to find primes.

The numbers involved are extremely large. The most recent
prime was found for k=27653 at n=9167433.

That's 27653*2^9167433+1, a nice 2,759,677 digits in decimal.

Trying to work with those kinds of things on a FPGA would be
madness.

Primality of these numbers can be proven with a Proth Test.

http://mathworld.wolfram.com/ can be useful too if you want
to read up any more on this.

Trying to prove primality of 2.7 million digit numbers is not
an easy task. It can take a month on a 3GHz Intel P4. The
equation involved is:
    let N=k*2^n+1
and if:-
    a^((N-1)/2) mod N = N-1
then N is prime. The value of a used is usually the lowest
odd prime that is not a factor of k. Since the remaining
k-values being tested are all prime then a=3 usually works.

Now consider the info above. In the above case N is a 2.7
million digit number. (N-1)/2 may have the same, or one digit
less than N. Still an insanely large number.

3^99 (a 2 digit number) results in a 49 digit number.
3^999 (a 3 digit number) results in a 478 digit number.

Now consider 3^N where N has 2.7 million digits.

Big.

Anyway, on to the sieving.

So the project has produced a large number of k,n pairs that
need to be tested. Each Proth test takes a long time.

Sieving is the process of removing candidate numbers by trial
division with known primes. For example, one of my computers
is checking the range of primes from
   882000000000000 to 883000000000000
and, amongst others, it's found that 882347066940847 is a
factor of 24737*2^80174983+1.

It has found 17 unique factors in the week that it has been
running. That's 17 k,n pairs that do not need to be proth
tested. Those proth tests would have run for 17 months on
the same machine only to not find any primes.

This is the value of sieving.

OK, so an FPGA won't be good at dealing with large (i.e.
10 million bit) numbers. So why am I here clogging up this
newsgroup with my ramblings?

It's because Proth numbers (k*2^n+1) have some properties
that make sieving easy.

Say I'm checking when k=10223 and my prime of choice is
p=882319864863617.

I compute the remainder of (k*2)+1 mod p. Which, when
testing such large primes, is simply (k*2)+1.

r = 10223*2+1 = 20447 (that's for n=1)

Starting with (k*2^n)+1
- subtract the 1 we added on =k*2^n
- double the number (k*2^n)*2 = k*2^(n+1)
- add one = (k*2^(n+1))+1

More importantly, these actions can be performed on the
remainder without having to keep track of the actual value
of k*2^n+1. So:-

r_next = (2*(r-1))+1 mod p = 2r-1 mod p

The 'mod p' part is quite expensive. Since we are only
dealing with a doubling of the previous r (which we knew
was guaranteed to be less than p) we know that, at most,
r could grow to less than 2p. This is why 'mod p' is
replaced by a simple subtraction of p if r >= p.

If r is ever equal to 1 then it will always remain 1, we
can stop processing (for the FPGA I wouldn't even bother
passing this on as a work unit).

If r is ever equal to 0 then it means that p is factor of
k*2^n+1 at whatever n the algorithm has iterated to. We can
stop here and record the value of n.

So with relatively little effort we can check for factors
for very large values of n without having to keep track of
the large (multi-million digit) values. The snag is that
we have to compute r for every n along the way.

This is why I can't run a coarser run by skipping values.
Each iteration must be performed and the value of r checked.
There is no way to predict future values of r without
computing them.

There's another stop condition, if we ever get back to the
r value we started at (when n=1) then we know we can stop.
The r values will just follow the same pattern again. At
this point I'd like to stop and record the fact that no
factor was found (otherwise I would have stopped before) for
this k,p pair.

The modulus operation involved has an important bearing on
the size of this loop. Say I'm checking a number against
p=3. Consider all of the possible values of r and what they
transform to:-

2x-1 mod 3

0 -> (2*0)-1 mod 3 == 2.
1 -> (2*1)-1 mod 3 == 1.
2 -> (2*2)-1 mod 3 == 0.

The maximum number of values r can have is p, but r=1 is
a special case, so the maximum loop size would be p-1.

Some values of p can produce smaller sub-loops.

2x-1 mod 7:

0-> (2*0)-1 mod 7 == 6.
1-> (2*1)-1 mod 7 == 1.
2-> (2*2)-1 mod 7 == 3.
3-> (2*3)-1 mod 7 == 5.
4-> (2*4)-1 mod 7 == 0.
5-> (2*5)-1 mod 7 == 2.
6-> (2*6)-1 mod 7 == 4.

0->6->4->0
1->1
2->3->5->2

So if my initial value of r had been 2 I could loop
endlessly without ever finding a factor (r=0). This is why
it's important to check to see if we've returned to the
initial value of r.

The sieving effort involved in the SoB project above has put
an arbitrary limit on the upper bound of n of 50 million.
Proth testing a k,n pair where n~50M would take a long long
time, but sieving up to that range is relatively cheap. If,
two years down the road, the project is looking at n values
up at that range we'll be thankful that we've sieved up
there.

As I said above, the maximum size of the loop is p-1. So
for p=882319864863617 this would mean a maximum loop size
of 882,319,864,863,616.

This is why 99.9% of the runs will completely iterate up to
n=50,000,000.

It's actually closer to 99.999999%. From the numbers above
there is a 1 in 17,646,397 chance that p will be a factor of
k*2^n+1 with n between 1 and 50,000,000.
(This isn't strictly true due to the possibility of smaller
sub-loops, but gives you an idea of the numbers involved).

Also, by recording the value of r when I do reach the end
of the loop it means I can continue this at a later date.
I'd only need r at n=1 (trivial to compute) and the value
of r at a given n and I can continue on my merry way.

The faster we can sieve, the faster we can rule out more
and more k,n pairs. The less pairs we have the faster
sieving becomes (although only slightly) and so we can sieve
out higher and higher primes.

*THIS* is why I'm interested in an FPGA helping out. They
have the capability of being much much faster than
traditional CPUs.

If you've read this far then thank you. Reward yourself
with a coffee/tea/walk/cigarette/nap/whatever.

Ta, -Alex


Article: 86503
Subject: read & write on SDRAM speed with PPC 300 MHz
From: "Pierre" <pierre.detrentinian@cnam.fr>
Date: Wed, 29 Jun 2005 13:07:09 +0200
Links: << >>  << T >>  << A >>
Hello

I use a Virtex-II Pro with PowerPC at 300 MHz, 8 kB IOCM, 32 kB DOCM and
external 32 MB SDRAM (connected on PLB )

 When I read 10 times 32 MB on my SDRAM, that takes 3.7'' and when I write
the 320MB on the SDRAM it takes 9.6'' without burst support  and 6" with
burst support.

Did someone knows why the read rate is 85 MByte/s for writting a SDRAM and
maximum 53 MB/s for reading ?
Normally, with 64 bits PLB, it should be much more ?

Pierre



Article: 86504
Subject: read & write on SDRAM speed with PPC 300 MHz
From: "Pierre" <pierre.detrentinian@cnam.fr>
Date: Wed, 29 Jun 2005 13:10:54 +0200
Links: << >>  << T >>  << A >>
Hello

I use a Virtex-II Pro with PowerPC at 300 MHz, 8 kB IOCM, 32 kB DOCM and
external 32 MB SDRAM (connected on PLB )

 When I read 10 times 32 MB on my SDRAM, that takes 3.7'' and when I write
the 320MB on the SDRAM it takes 9.6'' without burst support  and 6" with
burst support.

Did someone knows why the read rate is 85 MByte/s and 53 MB/s(maximum ) for
writing?

Normally, with 64 bits PLB, it should be much more ?

Pierre




Article: 86505
Subject: Re: Good FPGA for an encryptor
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Wed, 29 Jun 2005 11:20:16 GMT
Links: << >>  << T >>  << A >>

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:d9tjh9$lpo$1@news.netpower.no...
> Kolja Sulimma wrote:

>> Hmm. As I understand it, if the algorithm is known, a skilled attacker
>> will find the key with differential power analysis within hours if he
>> can take the board to the lab.

> I'm not an expert (I'm not even an amateur) in cryptography, but can you 
> not fool differential power analysis by adding extra logic to cause 
> unpredictable switching to swamp any useful power analysis?


If it is random noise, then one could collect many samples of the same 
cryptographic operation and average them out.

The noise averages toward zero, the signal increases with more samples.

So it puts the cryptanalyst to more trouble but not insurmountable.


In DAC chips, I noticed that bits would switch currents into the output 
circuit or a 'dumping' load.
This is done so there is a constant current load on the power rail and thus 
less noise to affect other bits.

Ideally a crypto device would do the same thing.

However, I should point out that all current FPGA chips are unsuitable for 
cryptography where a skilled attacker can get hold of it.
They are very regular in structure, relatively easy to probe, and not built 
with anti-analysis features.

Modern smart card chips are designed to make attack harder. Key bus and 
control lines might be buried so one has to etch as well as probe, data 
storage physically jumbled, and so on. They can still be analysed given 
enough time and money, but the aim is to make this more expensive than what 
the attacker can gain from the process.


That said, the Cambridge company N-Cypher uses FPGA chips in its 
web-encryption products.
These sit in the service provider's locations, so they are more secure than 
being out in the field.

K. 



Article: 86506
Subject: Re: V4 and NBTI question, again..
From: "Marc Randolph" <mrand@my-deja.com>
Date: 29 Jun 2005 05:00:45 -0700
Links: << >>  << T >>  << A >>

Antti Lukats wrote:
> [...]
> AR21127 says that if the V4 is powered but not configured the DCM
> performance will start to degrade (there are actuall changes of the
> silicon!), but this process is reversable, like self healing so if the V4 is
> later powered and configured for the same amount of time then DCM
> performance will slowly be restored to be inside the specification again.

Howdy Antti (or Austin),

Could you point me to where you saw something official from Xilinx
(unfortunately a newsgroup posting isn't official) about the DCM
recovering its max frequency specs after being configured or unpowered
for a period of time?  All I can find is a description it degrading.

BTW, the following answer record may be of interest to you and others:
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=21435

Thanks,

   Marc


Article: 86507
Subject: Re: Good FPGA for an encryptor
From: "Marc Randolph" <mrand@my-deja.com>
Date: 29 Jun 2005 05:11:41 -0700
Links: << >>  << T >>  << A >>


Antti Lukats wrote:
> "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
> news:d9rpon$lbe1@cliff.xsj.xilinx.com...
> > Comment:
> >
> > Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100
> > (based on forward pricing in quantities, see the various press releases).
> >
> > If this is a hobby project, then you are better off going to the Xilinx
> > web store and buying a Spartan 3 (or buying the Digilent S3 pcb complete).
>
> Hi Austin,
>
> I think my estimate was more realistic, it is for the small volume project
> (at least the way I understood the OP) and I did mean pricing as of today.
> Sure the prices for the devices you mentioned do fall below $100 margin,
> some day in some qty. But for buying small qty of V4 as of today I would
> expect near 100$ pricing or am I mis understanding the pricing policy? I
> dont remember seeing V4 price forecasts going much lower than $80 USD for
> 5-10k yearly volumes. Sure I would welcome a lower pricing :)

Howdy Antti,

   Agreed - the Xilinx press releases are near useless.  Looks like you
have to get into some decent quantity before the price drops below
$100:
http://groups.google.com/groups?q=xc4vfx12

   Marc


Article: 86508
Subject: Re: Maintaining a Pipeline
From: "valentin tihomirov" <spam@abelectron.com>
Date: Wed, 29 Jun 2005 15:31:47 +0300
Links: << >>  << T >>  << A >>
> Does it make sense to stick a circular buffer of size a bit bigger
> than N at the top of the pipeline, and tag each entry with a short
> quantity indicating where in the buffer its input is stored?

In my case, the pipeline input is not stored at all. However, it will be
needed at the moment the pipeline produces the output for that input. Any
recommendations?



Article: 86509
Subject: Re: SPD interface(Serial presence detect)
From: praveen.kantharajapura@gmail.com
Date: 29 Jun 2005 05:42:28 -0700
Links: << >>  << T >>  << A >>


David Brown wrote:
> >How will the master know that this byte is the last byte
>
> Can you be more specific on what you mean by this? (are you referring to the
> SPD controller, or the state machine or microprocessor controlling it?)

I am referring to SPD controller.
>
> >and what
> > happens if the master acknowledges the last byte also.
>
> Referring to the I2C spec Page 10, section 7.2, "If a master-receiver is
> involved in a transfer, it must signal the end of data to the
> slave-transmitter by not generating an acknowledge on the last byte that was
> clocked out of the slave. The slave-transmitter must release the data line
> to allow the master to generate a STOP or repeated START condition"
>
> I don't really know what will happen with the slave device you are using if
> you don't NACK the last byte, it might work just fine, or if the SPD puts
> out one additional clock at the end of the ACK bit position to release the
> ACK/NACK, the slave device would think the next byte should be read and
> would assert the MSB of the next byte on the data line. If the MSB of the
> next byte was a 0, then the master would not be able to apply a stop
> condition (remember it's open drain or wire AND), and the system would
> affectively be unsynchronized. The Master may believe it terminated the the
> read sequence correctly, and the slave could still be driving the data line
> low with it's MSB waiting to shift out the next bit for the byte.
> Following communications to the slave device would fail, until the master
> outputs a continuous 1 (0xFF) pattern to the device allowing the device to
> eventually get a NACK and terminate the read operation. The master could
> then attempt to repeat the sequence for a read operation..
>
> Based on the spec. and the possibilities of what you can look forward to and
> the corrective actions,  I would recommend following it for compatibility
> reasons.
>
> dbrown
>
>
>
> <praveen.kantharajapura@gmail.com> wrote in message
> news:1118720948.402364.49090@g49g2000cwa.googlegroups.com...
> >
> >
> >
> >
> > David Brown wrote:
> >> One additional note. As mentioned below, the master should ACK each byte
> >> that it reads, except for the last byte. The last byte should be nacked
> >> prior to the stop condition.
> >>
> >
> > How will the master know that this byte is the last byte, and what
> > happens if the master acknowledges the last byte also.
> >
> >
> >
> >
> >> dbrown
> >>
> >> "Gabor" <gabor@alacron.com> wrote in message
> >> news:1118690295.803563.225360@g43g2000cwa.googlegroups.com...
> >> > praveen.kantharajapura@gmail.com wrote:
> >> >> Hi Gabor ,
> >> >>
> >> >> Thanks for the reply. My EEPROM is write protected i will only be
> >> >> reading the first 128 bytes, is this flow diagram all right.
> >> >>
> >> >>
> >> >>       1-bit                    8-bits
> >> >> 1-bit
> >> >>
> >> >> Start from master  --->>  EEPROM Slave address("10100001") -->> ACK
> >> >> from eeprom --->>
> >> >
> >> > Actually you need to start with write address "10100000" in order
> >> > to write the address register (you don't need to write the EEPROM
> >> > array so write protect doesn't matter).
> >> >
> >> >>
> >> >>
> >> >>         8-bits                            1-bit
> >> >> Write register address "00000000"  --->> ACk from EEPROM
> >> >
> >> > Right here you need to switch to read mode.  There are two
> >> > ways to do this.  Either master sends Stop followed by Start
> >> > or master sends repeated start.  If you intend to reuse this
> >> > code for other peripherals besides EEPROM, you'll find the
> >> > repeated start is compatible with more chips.
> >> >
> >> > Then you need to provide slave address "10100001" for read
> >> > and get ack from slave then:
> >> >
> >> >>         8-bits                            1-bit
> >> >>  --->> Data[0]
> >> >> from EEPROM --->> ACK from master
> >> >>
> >> >>                             8-bits                1-bit
> >> >>
> >> >> ................. --->>Data[127] from EEPROM --->> STOP from master
> >> >>
> >> >> I will generate the STOP condition after receiving 128 bytes.
> >> >>
> >> >> Any comments on this.
> >> >>
> >> >>
> >> >> Regards,
> >> >> Praveen
> >> >>
> >> >>
> >> > Also you talk about "bits" when you send start and stop.  These
> >> > conditions
> >> > do not toggle the SCL line so they are not usually counted as "bits"
> >> > as would be data or Ack cycles.
> >> >
> >> > Regards,
> >> > Gabor
> >> >
> >


Article: 86510
Subject: Re: proth siever in FPGA? [LONG]
From: "JJ" <johnjakson@yahoo.com>
Date: 29 Jun 2005 05:59:10 -0700
Links: << >>  << T >>  << A >>
Alex wrote:
> Thanks for the comments (Andrew & JJ). Let me explain a bit.
> You asked for this! :-)
>
> I don't need an FFT because I don't need to multiply numbers.
> The sieving can be performed on 'small' integers (64-bits
> gives a very large scope) using addition, subtraction, left
> shifting by one bit and comparisons.
>
> No multiplication and no floating-point makes it much
> easier.
>


snipping all to spare the BW

Well that was quite an interesting read and links too.

Right now its still over my head since its not my hobby or work
interest but still it points to the challenges in an FPGA design. But
since I know the simple seive of eratosthenes very well I'll come back
to this later as a possible cpu/memory benchmark.

I think starting with the starter kit is an excellent idea, when you
reach best case solution you can atleast speculate what bigger HW could
do.

On the other hand you could avoid this HW experiment and keep it in C
for quite a while longer. When I model my cpu project, I don't use
Verilog simulation, I write in a form of HDL C that allows the C model
to run in std VC6 compiler on a std PC, this C RTL (register transfer
level) code runs about 20x slower than simple minded C code that has no
HW detail but it also runs orders faster than Verilog simulation. The C
RTL code though looks so much like Verilog it can be hand translated
with some grepping back into Verilog for the actual FPGA synthesis.
This might not be so easy for VHDL since its syntax is not like C.

You could reasonably experiment with C RTL engines that are orders
magnitude larger than any FPGA could actually handle and you still have
the PC memory and disk resources. So far you are going backwards by
about 20x if you do what I suggest, but then with a simple C RTL
translation effort you have a Verilog that can be synthesized into any
FPGA provided you understood the architecture of the FPGA. Now with the
C RTL model you can have your simulator count cycles and HW costs
without ever going to HW. But you will need to port the C RTL to
Verilog to find out what your clock freq limit is going to be.

What I like about this approach is that lots of architectures can be
explored and with my HW exp in hand I know what to expect when I go to
synthesis. Exploring architecture is relatively painless in your fav C
IDE, but you can evolve the arch towards one that just flies through
the FPGA tools. Spending alot of time in Webpack trying to get optimal
results leads to great frustration. You might also look at HandelC but
$$$.

For the long term, I still think big DRAM is going to be a big
heasdache since I see poor locality of reference written all over this
project, ie SRAM cache will be useless. You could take a look at
Micron's RLDRAM which performs like a DRAM in density and like an SRAM
in speed. It does this by allowing accesses to start every 2.5ns, with
8 in flight and data accesses come out after 20ns or 8 clocks. If you
can arrange for interleaved engines to sync with this, you can get
32MByte RLDRAM effectively working at 2.5ns but you need good HW
pipeline design, and this is high end FPGA stuff ie V2Pro and above.
These accesses can be fully random to any address provided the bank is
already done with previous job.

For spartan3 best grade, webpack 6.3 was giving me 225MHz or so for a
16bit cpu datapath with the 16bit adder and dual port blockram both
close to the limit. I use 2 clocks to get a 32bit datapath with 4way
ported BRam. Others here may have gotten better results. I mostly work
on V2Pro about 1.5x faster, and it seems webpack 7.1 has slowed things
down some (I dunno why).

If you start adding numbers >16b unpipelined, your perf will go to hell
pretty quickly, you need to pipeline either at the 16b or 32b add
level.

best of luck to this project

regards

johnjakson at usa dot com

ps 
If you like I can send you C RTL sample code.


Article: 86511
Subject: Re: ADPLL for NRZ
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Wed, 29 Jun 2005 09:01:44 -0400
Links: << >>  << T >>  << A >>
Alex,

I think there is a nice book on this subject written by Best.

Here is its full name:
R. E. Best. Phase-Locked Loops Design Simulation and Applications. The 
McGraw-Hill Companies, New York, New York, 1999

What is the maximum NRZ data rate? If it's small enough to be oversampled by 
higher frequency clock, there could be an alternative implementation.
You can use a self-resettable NCO which is reset to a seed FTW each NRZ 
posedge / negedge.

Hope this helps.

Vladislav

"Alex" <jovajsha@yahoo.com> wrote in message 
news:4Stwe.1813$R5.506@news.indigo.ie...
> Hi,
>
> I am trying to find some literature of how to design All Digital PLL which
> would extract clock from NRZ signal. The main problem here is that zero
> crossing is not present every bit. Also, does anyone know how to set 
> digital
> filter parameters (in practice) based on loop bandwidth, tracking band and
> parameters like that? Thanks.
>
> Alex
>
>
> 



Article: 86512
Subject: Quatech SPP-100 programs/verifies successfully but device is not "programmed"
From: "irish" <decalternate@hotmail.com>
Date: 29 Jun 2005 06:17:50 -0700
Links: << >>  << T >>  << A >>
I am using the Quatech SPP-100 PCMCIA parallel port emulator with a
Dell M70. Everything looks great. When I program the PROM (XCF08S) it
programs and verifies successfully. The FPGA does not get programmed
correctly however by the PROM on power up. Then I tried programming the
FPGA, Virtex 4 FX12, and same thing, programs and verifies successfully
but does not run. Then I tried programming the FPGA without
verification. Then it works fine. I tried the PROM without verification
with no success. It seems the only thing that I can do is program the
FPGA without verification.

By the way the same program runs fine when programmed from a different
machine with a dedicated parallel port.

Anyone seen this before and if so any possible solutions?

Cheers,

irish


Article: 86513
Subject: Hex files in simulation
From: ALuPin@web.de
Date: 29 Jun 2005 06:18:00 -0700
Links: << >>  << T >>  << A >>
Hi,

in my simulation I have a dual port Ram (from QuartusII v.5.0) which is
initialized to all zeros with a hex file.

My problem:

After some write operations into the RAM (32 write positions
are provided by a FIFO module) I want to reset my design in my
VHDL simulation (Modelsim) because the FIFO is empty. The present
state of design does not allow to put back the write positions
into my FIFO.

After the FIFO is empty I could reset my design within my testbench.
But the contents of the RAM should also be resetted or rather
be initialized again with zeros. I could step through my RAM
and write at each address zeros into it but that takes too long
for simulation. The hex file seems to have a bearing on initialization
only at the beginning of the simulation.

Is there some possibility to initialize the RAM during simulation
by means of the hex file ?

Any suggestions are appreciated.

Rgds
Andr=E9


Article: 86514
Subject: synthesis problem
From: "Joey" <johnsons@kaiserslautern.de>
Date: Wed, 29 Jun 2005 15:18:47 +0200
Links: << >>  << T >>  << A >>
Hello

I have a strange problem. I am trying to implement a decoder as a plb
peripheral. The problem appears when I am trying to synthesis the core.
Sometimes it synthesises properly using up 34 block rams. But sometimes, it
doesn't. Can anybody give any reasonable explanations for this. I am using
Xilinx XPS for synthesising and downloading. I have the IMP_NETLIST = TRUE
in my .mpd file.

Joey



Article: 86515
Subject: Re: ADPLL for NRZ
From: "Alex" <jovajsha@yahoo.com>
Date: Wed, 29 Jun 2005 14:26:44 +0100
Links: << >>  << T >>  << A >>
Thanks Vladislav,

I will browse net for your suggestions. BTW, NRZ in this case can and will
be oversampled by 16 times.

Alex
"Vladislav Muravin" <muravinv@advantech.ca> wrote in message
news:YYwwe.8234$mK5.579394@news20.bellglobal.com...
> Alex,
>
> I think there is a nice book on this subject written by Best.
>
> Here is its full name:
> R. E. Best. Phase-Locked Loops Design Simulation and Applications. The
> McGraw-Hill Companies, New York, New York, 1999
>
> What is the maximum NRZ data rate? If it's small enough to be oversampled
by
> higher frequency clock, there could be an alternative implementation.
> You can use a self-resettable NCO which is reset to a seed FTW each NRZ
> posedge / negedge.
>
> Hope this helps.
>
> Vladislav
>
> "Alex" <jovajsha@yahoo.com> wrote in message
> news:4Stwe.1813$R5.506@news.indigo.ie...
> > Hi,
> >
> > I am trying to find some literature of how to design All Digital PLL
which
> > would extract clock from NRZ signal. The main problem here is that zero
> > crossing is not present every bit. Also, does anyone know how to set
> > digital
> > filter parameters (in practice) based on loop bandwidth, tracking band
and
> > parameters like that? Thanks.
> >
> > Alex
> >
> >
> >
>
>



Article: 86516
Subject: Clock buffering in VirtexE FPGA
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 29 Jun 2005 06:52:01 -0700
Links: << >>  << T >>  << A >>
I am new to this group and new to FPGA. I am working with XCV2000E
fpga. Tool i am using for synthesiz is Xilinx ISE 6.2i. I am working
with logic module provided by ARM. I need to interface a push button
switch provided in the board.
But whenever i use the edge of this signal for triggering in the code(i
am using verilog) xilinx tool assumes it as a clock signal and ties it
to default pins provided in the FPGA. But this pin is difffernt from
the push button input. How can i reassign the input to the push button
switch. How can i disable the clock bufferenig in the tool.
One method i found is change in the code. insted of directly clocking
with push button i passed it through an and gate. This removed buffring
of the push button.
Eg:
insted of
always @(posedge pbut)
i used
assign temp_clk = pbut & pbut_enable;
always @(posedge temp_clk)

where pbut_enable is an external signal and assigned LVTTL type to it
(this i hope when unconnected will keep the pbut_enable at "high"
state").
Will this method work. Anyway i want to know about clock disabling in
the tool
Hope you people will help me. Thank you.


Article: 86517
Subject: Re: ADPLL for NRZ
From: "Alex" <jovajsha@yahoo.com>
Date: Wed, 29 Jun 2005 15:03:58 +0100
Links: << >>  << T >>  << A >>
Vladislav,

Could you please explain to me what did you mean by "reset to a seed FTW"?
Many thanks.

Alex
"Vladislav Muravin" <muravinv@advantech.ca> wrote in message
news:YYwwe.8234$mK5.579394@news20.bellglobal.com...
> Alex,
>
> I think there is a nice book on this subject written by Best.
>
> Here is its full name:
> R. E. Best. Phase-Locked Loops Design Simulation and Applications. The
> McGraw-Hill Companies, New York, New York, 1999
>
> What is the maximum NRZ data rate? If it's small enough to be oversampled
by
> higher frequency clock, there could be an alternative implementation.
> You can use a self-resettable NCO which is reset to a seed FTW each NRZ
> posedge / negedge.
>
> Hope this helps.
>
> Vladislav
>
> "Alex" <jovajsha@yahoo.com> wrote in message
> news:4Stwe.1813$R5.506@news.indigo.ie...
> > Hi,
> >
> > I am trying to find some literature of how to design All Digital PLL
which
> > would extract clock from NRZ signal. The main problem here is that zero
> > crossing is not present every bit. Also, does anyone know how to set
> > digital
> > filter parameters (in practice) based on loop bandwidth, tracking band
and
> > parameters like that? Thanks.
> >
> > Alex
> >
> >
> >
>
>



Article: 86518
Subject: Re: Linux 2.6 on the Xilinx ML310 board
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 29 Jun 2005 07:31:01 -0700
Links: << >>  << T >>  << A >>
I could run the 2.6 kernel without PCI support on the ML 310 board
..But I havent written any document on that ..Let me know in case u
need help.. 

--
Parag Beeraka


Article: 86519
Subject: Re: synthesis problem
From: Sean Durkin <smd@despammed.com>
Date: Wed, 29 Jun 2005 16:37:37 +0200
Links: << >>  << T >>  << A >>
Joey wrote:
> Hello
> 
> I have a strange problem. I am trying to implement a decoder as a plb
> peripheral. The problem appears when I am trying to synthesis the core.
> Sometimes it synthesises properly using up 34 block rams. But sometimes, it
> doesn't. Can anybody give any reasonable explanations for this.
A little more info would be helpful... What happens if it doesn't
synthesize "properly"? Any error messages?

cu,
Sean

Article: 86520
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Jun 2005 07:41:22 -0700
Links: << >>  << T >>  << A >>
Kolja,

No one has proven that DPA can crack the decryption on the V2, V2Pro, 
nor V4 .... yet.

And it isn't for the lack of trying.

So, the challenge remains:  Can DPA crack 3DES or 256AES as implemented 
in V2, 2Pro, or V4?

Austin

Kolja Sulimma wrote:

> Piotr Wyderski schrieb:
> 
>>Hello,
>>
>>I would like to build a 1GBit/s data encryptor/decryptor using
>>an FPGA chip, but I have a big problem with an appropriate
>>chip. It should contain about 3000LE, 70 IO pins and at least
>>12 dual-port RAM blocks (I need two read ports per block) configurable
>>as 512x8 banks. Additionally, it should be Flash-based or SRAM
>>-based with encrypted bitstream. And must be cheap. Here are the
>>options I know of:
> 
> 
> Hmm. As I understand it, if the algorithm ist known, a skilled attacker
> will find the key with differential power analysis within hours if he
> can take the board to the lab.
> So you do not gain much by an encrypted bitstreams or even a OTP part.
> You only prevent amateurs from breaking your chip, but they can always
> pay an expert.
> 
> You can ofcourse invent your on algorithm and keep it secret, but I
> doubt that this will be any more secure.
> 
> The only way to be safe is to make sure the key never ands up in a
> hostile lab, for example by carrying it around on a keychain.
> 
> Kolja Sulimma

Article: 86521
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Jun 2005 07:51:29 -0700
Links: << >>  << T >>  << A >>
Kryten,

I disagree:  Virtex 4 FPGAs may be the only really secure means of 
developing a good crypto application.

What can be more regular than an ASIC?  It is all there, every bit of 
information, to be sliced and diced.

With an encrypted bitstream in an FPGA, there is an additional level of 
encryption that makes it even harder to crack.  Not only is the design a 
secret, and its implementation, but the attacker does not even know 
where any wires of interest, or any bits of interest are being kept.

Additionally, security minded companies do not need to have a "secure 
foundry" build their chips:  any foundry that makes the FPGA 'could' 
modify the masks, but that can be easily detected by comparing the FPGA 
with the original mask set (simple inspection).

Attacks of DPA, flipping individual bits with laser/particle beams, etc. 
all fail due to the immense complexity of the problem.  The FPGA with a 
billion transistors is not a stupid 'smart card' running a simple 8 bit 
uP program than can be easily spoofed.

I have challenged, and continue to challenge anyone to crack the FPGA 
security (only by breaking it can we make it better).

To that end, we still have some USB V2 Pro Logic Vault cards that are 
available for serious security hacking.

Austin


Kryten wrote:

> "David Brown" <david@westcontrol.removethisbit.com> wrote in message 
> news:d9tjh9$lpo$1@news.netpower.no...
> 
>>Kolja Sulimma wrote:
> 
> 
>>>Hmm. As I understand it, if the algorithm is known, a skilled attacker
>>>will find the key with differential power analysis within hours if he
>>>can take the board to the lab.
> 
> 
>>I'm not an expert (I'm not even an amateur) in cryptography, but can you 
>>not fool differential power analysis by adding extra logic to cause 
>>unpredictable switching to swamp any useful power analysis?
> 
> 
> 
> If it is random noise, then one could collect many samples of the same 
> cryptographic operation and average them out.
> 
> The noise averages toward zero, the signal increases with more samples.
> 
> So it puts the cryptanalyst to more trouble but not insurmountable.
> 
> 
> In DAC chips, I noticed that bits would switch currents into the output 
> circuit or a 'dumping' load.
> This is done so there is a constant current load on the power rail and thus 
> less noise to affect other bits.
> 
> Ideally a crypto device would do the same thing.
> 
> However, I should point out that all current FPGA chips are unsuitable for 
> cryptography where a skilled attacker can get hold of it.
> They are very regular in structure, relatively easy to probe, and not built 
> with anti-analysis features.
> 
> Modern smart card chips are designed to make attack harder. Key bus and 
> control lines might be buried so one has to etch as well as probe, data 
> storage physically jumbled, and so on. They can still be analysed given 
> enough time and money, but the aim is to make this more expensive than what 
> the attacker can gain from the process.
> 
> 
> That said, the Cambridge company N-Cypher uses FPGA chips in its 
> web-encryption products.
> These sit in the service provider's locations, so they are more secure than 
> being out in the field.
> 
> K. 
> 
> 

Article: 86522
Subject: Re: V4 and NBTI question, again..
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Jun 2005 08:00:19 -0700
Links: << >>  << T >>  << A >>
Marc,

Contact your FAE for information.

The information packet on this subject states the shift in Vt is 
reversable.

Austin

Marc Randolph wrote:

> Antti Lukats wrote:
> 
>>[...]
>>AR21127 says that if the V4 is powered but not configured the DCM
>>performance will start to degrade (there are actuall changes of the
>>silicon!), but this process is reversable, like self healing so if the V4 is
>>later powered and configured for the same amount of time then DCM
>>performance will slowly be restored to be inside the specification again.
> 
> 
> Howdy Antti (or Austin),
> 
> Could you point me to where you saw something official from Xilinx
> (unfortunately a newsgroup posting isn't official) about the DCM
> recovering its max frequency specs after being configured or unpowered
> for a period of time?  All I can find is a description it degrading.
> 
> BTW, the following answer record may be of interest to you and others:
> http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=21435
> 
> Thanks,
> 
>    Marc
> 

Article: 86523
Subject: Re: Hex files in simulation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 29 Jun 2005 08:39:47 -0700
Links: << >>  << T >>  << A >>
ALuPin@web.de wrote:


> After the FIFO is empty I could reset my design within my testbench.

Yes, just push more data in using the testbench.

> But the contents of the RAM should also be resetted or rather
> be initialized again with zeros.

That's not what will happen on the bench.
A fifo can only access data it has pushed in.
You want 'U's elsewhere to make sure your
head and tail counters are working ok.

        -- Mike Treseler



Article: 86524
Subject: Re: Good FPGA for an encryptor
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Wed, 29 Jun 2005 16:42:10 +0100
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> wrote in message
news:d9uchh$ico1@cliff.xsj.xilinx.com...

> With an encrypted bitstream in an FPGA, there is an additional level of
> encryption that makes it even harder to crack.  Not only is the design a
> secret, and its implementation, but the attacker does not even know
> where any wires of interest, or any bits of interest are being kept.

FPGAs also give you yet another level of security here. For any given
circuit functionality, and given sufficient timing/size margin, there are
billions of different placement and routing combinations that will do the
same thing. One could quite easily automate the process of creating a new,
individual bitstream for each device to be shipped - particularly in Piotr's
case, since he is talking of very small production runs.

This technique doesn't help you against an attack on an individual device,
of course. What it *does* mean is that cracking device X doesn't help you to
crack device Y as well, because all the wires and logic elements are in
different places. You'd have to start again from scratch. The avalanche
effect in the bitstream encryption makes each (bitstream, device)
combination into a completely unique problem. This would be reassuring to a
customer wanting to buy a large number of these magical crypto chips.

Cheers,

        -Ben-





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