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

taniwha taniwha at taniwha.com
Sun Sep 19 21:54:39 EDT 1999



>taniwha wrote:
>
>> it's more than that - it takes 3x26 turns through the datapath (ie 3x26
>> clocks) - with storage for 26 32-bit sets of intermediate values - I 
>> think you can fit it in a sub $50 FPGA (just) but I'd doubt you can 
>> get it to run at over 50MHz for 50/(3*26) = ~640Kk/sec

>> you aren't going to get really high key rates without either lots of
>> silicon or lots of clocks


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

sure - to do this you'd need to unroll all 3x26=78 pipe stages 
each of which has a few adders and a few shifters and muxes - plus 
there's feedback into the circuit from 26 clocks before so
you need somewhere to store all that stuff in the mean time
(this is an N**2 pipe resource so it's bigger than you think
2*26*26*32-bits I think)

Just for a lark a while back I unwound everything into one big 
combinatorial statement and fed it to synopsys - my workstation
ran out of swap space after 7 hours ..... it's a BIG
problem (but then this is not a bad thing - for a good encryption 
algorithym it should be a big problem :-)

As I said above I think you need either a lot of clocks or a lot of
silicon (your design would be at the 'lot of silicon' end of the 
spectrum - and would probably take roughly the same area as
25 1Mkey/sec engines laid down side-by-side - it probably won't
fit on a $100 FPGA.

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



More information about the Hardware mailing list