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