Re: "success"

"Dan Oetting" <dan_oetting-r9/[email protected]> Fri, 20 Oct 2006 22:08:03 -0600
Newsgroups gmane.comp.distributed-net.hardware
Message-ID <[email protected]>
On Oct 20, 2006, at 7:11 AM, [email protected] wrote:

> Talking about devices, if the biggest device you "can" (afford) work
> with is a Spartan3E, there is maximum 14.5 kSlices and 36 bRAMS.
>> From my point of view, it is not possible to fit a fully unrolled RC5
> core with such amount of slices. (or I will be very happy to know
> how!).
> For such kind of devices, a partially unrolled core should probably be
> the best solution (with let's say 3 key schedule stages and 1 decrypt
> stage).

You either need to compute the L[ ] values to feed into the first  
round of each key schedule stage or save the S[ ] values for each  
iteration between stages. You could generate the L[ ] values by  
running your 3 stages through 3 passes with the same key to generate  
and pass the required values. Alternatively, you could replicate the  
early key schedule stages and feed them with the next 2 keys to be  
processed. You would then have a total of 6 key schedule stages and 1  
decrypt stage but only need 1 pass per key and no S[ ] storage. I  
figure that's about a 40% savings.

If you then unroll the loop you get a pure logic cascade with no  
storage requirements.

-- Dan Oetting

_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware