[HARDWARE] Just Courious......]]

taniwha taniwha at taniwha.com
Tue Sep 21 06:33:58 EDT 1999

On Mon, 20 Sep 1999, Dennis Lubert wrote:
> At 14:48 19.09.99 -0500, you wrote:
> >Maybe I'm not understanding this right, but if the algorithm is fully 
> >unrolled, that is to say
> >fully pipelined, wouldn't you get one answer out with each clock? So even a 
> >lowely 25Mhz FPGA
> >would be cranking out 25MKeys/sec.   Even if two $50 parts were needed, that 
> >would make a $150
> >box that did 25Mkeys/sec, or $6/Mkey/sec, still a great deal!

> You are all talking about the algorithm, and I looked it up in the net, but
> noone could really tell me how it is working. Perhaps someone could tell us
> so we can understand how and why u can't get one answer with each clock
I think the thing to understand is not that you can't do 
it in one clock it's just that the logic to do it in one
clock is fiendishly expensive - something like a pile
of adders and barrell shifters 80-odd deep - not only 
that but the controlls on the rotates are wired to the 
outputs of some of the adders - it's a combinatorial 
nightmare - any sort of sythesis tool's probably gonna barf
(synopsys did when I tried it). To reduce the amount of logic 
you use the fact that it's really the same operations being 
performed over and over again and then use a single datapath
reused over several clocks with some sort of memory to hold
the partialy done stuff 

Worst case timing through a structure like this will be 
very slow, most of the logic will be sitting idle while 
that path settles if you are going to throw enough 
logic at it to do one key/clock it would be better 
to pipe it anyway and run the same datapath
through many pipe stages with a much higher clock rate
this is a problem for which we don't care about latency
but we do care about throughput 

In short you can do it with one clock - it's going to take
a lot of silicon and a very long (ie slow) clock

	Paul Campbell
To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net

More information about the Hardware mailing list