Re: RC5 with FPGAs

IIRC, you don't need a lot of temporary storage with a pipelined core 
because the temporary storage is in the output flip-flops of each stage.
I suppose an interesting project would be a sort of CPU that was highly 
optimized for this operation but could do other things as well.
--
Martin

Olivier Meyer wrote:
> What you can do, is run several cores at the same time, if you have 
> enough area. That way, a large, slow chip can beat a small, fast chip. 
> This can get you a better (key per second)/(cost) ratio.
>
> On 9/6/06, *david fleischer* <cilantro_il-/[email protected] 
> <mailto:cilantro_il-/[email protected]>> wrote:
>
>     Sounds like a good idea.
>
>     > On 9/5/06, Fugu <[email protected]
>     <mailto:[email protected]>> wrote:
>     > >
>     > > By the way, I am also working on a FPGA
>     > implementation.
>     > > A technique that can accelerate keyspeed is this:
>     > > 1) Use pipelining
>     > > 2) Have the maximum numbers of decryption engines,
>     > as to use all the
>     > > gates.
>     > > BTW, posting your core on opencores.org <http://opencores.org>
>     would
>     > enable it to be checked for
>     > > bugs and improved.
>
>     You can probably add it to your list below as 3)
>     Collect optimization parameters for each FPGA device.
>
>     By the way, I'm not sure pipelining will bring you
>     great benefits in an FPGA. A back of the laptop
>     calculation tells me that you'll need approximately
>     1Kbit of memory per key. This may mean that most of
>     the archirecture will be shoveling data back and forth
>     to the core.
>
>     I also have a question, can someone help me figure out
>     the code in the source ANSI cores? I cannot understand
>     how the key increment is done. (that is to say, I see
>     what the code is doing, but I cannot figure out why
>     this does any good.)
>
>     Code snippet included below:
>         #define key rc5_72unitwork->L0
>         key.hi = (key.hi + 0x01) & 0x000000FF;
>         if (!key.hi)
>         {
>           key.mid = key.mid + 0x01000000;
>           if (!(key.mid & 0xFF000000u))
>           {
>             key.mid = (key.mid + 0x00010000) & 0x00FFFFFF;
>             if (!(key.mid & 0x00FF0000))
>             {
>               key.mid = (key.mid + 0x00000100) &
>     0x0000FFFF;
>               if (!(key.mid & 0x0000FF00))
>               {
>                 key.mid = (key.mid + 0x00000001) &
>     0x000000FF;
>                 if (!key.mid)
>                 {
>                   key.lo = key.lo + 0x01000000;
>                   if (!(key.lo & 0xFF000000u))
>                   {
>                     key.lo = (key.lo + 0x00010000) &
>     0x00FFFFFF;
>                     if (!( key.lo & 0x00FF0000))
>                     {
>                       key.lo = (key.lo + 0x00000100) &
>     0x0000FFFF;
>                       if (!(key.lo & 0x0000FF00))
>                       {
>                         key.lo = (key.lo + 0x00000001) &
>     0x000000FF;
>                       }
>                     }
>                   }
>                 }
>               }
>             }
>           }
>         }
>         #undef key
>
>
>
>     --- Fugu < [email protected] <mailto:[email protected]>> wrote:
>
>     > Doing a quick survey of the hardware list, there
>     > seems to be many people(me
>     > included), that seem, to various stages, to be
>     > dabbling with an FPGA (or
>     > other soft silicon) implementation.
>     > I hereby propose that we make a central area for
>     > such developments, to
>     > coordinate development.
>     > Another techinical idea: Instead of fine tuning each
>     > implementation to each
>     > FPGA, we could have one "main" code, and use a core
>     > generator program to
>     > tune it to each individual FPGA, to allow for
>     > maximum optimization.
>     >
>     >
>     > On 9/5/06, Fugu <[email protected]
>     <mailto:[email protected]>> wrote:
>     > >
>     > > By the way, I am also working on a FPGA
>     > implementation.
>     > > A technique that can accelerate keyspeed is this:
>     > > 1) Use pipelining
>     > > 2) Have the maximum numbers of decryption engines,
>     > as to use all the
>     > > gates.
>     > > BTW, posting your core on opencores.org <http://opencores.org>
>     would
>     > enable it to be checked for
>     > > bugs and improved.
>     > >
>     > >
>     > > On 6/14/06, Jim C. Nasby <
>     > [email protected] <mailto:[email protected]> > wrote:
>     > > >
>     > > > On Wed, Jun 14, 2006 at 03:13:04PM -0600, Fugu
>     > wrote:
>     > > > > One could do hardware error detection by
>     > re-encrypting the "decrypted"
>     > > > > message by the same key, and comparing it to
>     > the given message.
>     > > >
>     > > > Yes, but that gives much less protection than
>     > checking things on the
>     > > > server does.
>     > > > --
>     > > > Jim C. Nasby, Database Architect
>     > [email protected] <mailto:[email protected]>
>     > > > Give your computer some brain candy!
>     > www.distributed.net <http://www.distributed.net> Team #1828
>     > > >
>     > > > Windows: "Where do you want to go today?"
>     > > > Linux: "Where do you want to go tomorrow?"
>     > > > FreeBSD: "Are you guys coming, or what?"
>     > > > _______________________________________________
>     > > > Hardware mailing list
>     > > > Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
>     <mailto:Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]>
>     > > >
>     >
>     http://lists.distributed.net/mailman/listinfo/hardware
>     > > >
>     > >
>     > >
>     > >
>     > > --
>     > > FIN|ACK
>     > >
>     >
>     >
>     >
>     > --
>     > FIN|ACK
>     > > _______________________________________________
>     > Hardware mailing list
>     > Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
>     <mailto:Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]>
>     >
>     http://lists.distributed.net/mailman/listinfo/hardware
>     >
>
>     _______________________________________________
>     Hardware mailing list
>     Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected] <mailto:Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]>
>     http://lists.distributed.net/mailman/listinfo/hardware
>
>
>
>
> -- 
> -----------------------
> Olivier V. Meyer
> Congress shall make no law respecting an establishment of religion, or 
> prohibiting the free exercise thereof; or abridging the freedom of 
> speech, or of the press; or the right of the people peaceably to 
> assemble, and to petition the government for a redress of grievances.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Hardware mailing list
> Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
> http://lists.distributed.net/mailman/listinfo/hardware
>   

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