[Hardware] Fully unrolled RC5 on FPGA

Nathan Klassen klassenn at uregina.ca
Wed Nov 15 23:57:05 EST 2006


If we are talking about using a GPU the following links will be useful.

http://www.gpgpu.org/
A general site with tons of general computing on GPU information

http://graphics.stanford.edu/projects/brookgpu/

"Brook for GPUs is a compiler and runtime implementation of the Brook 
stream program language for modern graphics hardware." C, C++ etc.

NVIDIA's C based compiler for GP-GPU stuff
http://developer.nvidia.com/object/cuda.html

ATI's Stream Computing Page
http://ati.amd.com/technology/streamcomputing/index.html

Recent Wired article about GPU potential (yes its wired but for those 
looking for something less technical)
http://www.wired.com/news/technology/computers/0,72090-0.html?tw=wn_index_9

Personally I'm more interested in the purchase of a decent graphics card 
and using it for RC5/OGR than I am in an ASIC solution, but its neat to 
see all this work and revival of this list :)

- Nathan Klassen


Kris Amy wrote:
> What sort of GPU would be needed? I have a spare 7900GS that could be thrown
> to the cause.
> 
> Cheers,
> Kris
> 
> -----Original Message-----
> From: Frédéric Bastien [mailto:nouiz at nouiz.org] 
> Sent: Thursday, 16 November 2006 8:58 AM
> To: Hardware
> Subject: Re: [Hardware] Fully unrolled RC5 on FPGA
> 
> Hi,
> 
> The current GPU are being transformed to stream processor. I assume we 
> can transform the RC5 algorithm on this architecture by streaming the 
> key to the engines. But I never coded for GPU or the RC5. I suppose, 
> this approach will be not have an optimized processor as an ASIC or an FPGA.
> 
> But, how many people are ready to buy a new board for this purpose? How 
> many people who buy new computer with a good GPU will accept to share 
> it? What I'm telling is that I think their is more people in the second 
> group. I see it as the same reason why we use a distributed architecture 
> instead of buying a super-super-computer. It is cheaper as people 
> already have the hardware and the power cost is not counted by the 
> individual who install the software.
> 
> But as all project, we need people who can invest time in them. I can't. 
> Their is people that are interested to make an implementation on FPGA. 
> This is GREAT and give more chance that this will be done especially 
> since their is a working implementation. But, they need to finish the 
> last step.
> 
> Just my personal thinking on this project. Continue the good work!!
> 
> Frédéric Bastien
> 
> Olivier Meyer wrote:
>> Folding at home is trying to use graphic cards, but there is one reason 
>> why FPGA is much better:
>> A graphics card is NOT DESIGNED to execute general purpose code. It is 
>> made to render video and 3D images. What Folding has done is they have 
>> managed to use the restricted instruction set to do their 
>> protein-folding stuff. An FPGA design is the one thing less customisable 
>> than an ASIC. We can choose whatever we want to put on the FPGA, and we 
>> can make it check 1 key/cycle. I wonder, can our FPGA implementation be 
>> used on cheap, low power FPGAs that a student can afford (hint, hint!).
>>
>> Has anyone tried to use 74HC discrete logic to make an RC5-72 core?
>>
>>
>> On 11/15/06, *Frédéric Bastien* <nouiz at nouiz.org 
>> <mailto:nouiz at nouiz.org>> wrote:
>>
>>     To my knowledge Folding at home try to use graphic card and not FPGA.
>>     This could be interesting as this don't require new hardware. But we
>>     will need people that have time to implement it.
>>
>>     Frédéric Bastien
>>
>>     Olivier Meyer wrote:
>>      > If we will use a microcontroller to control the FPGA, an AVR
>>     would be
>>      > much better than a PIC for many reasons:
>>      > *more register space
>>      > *a GCC port
>>      > *higher speed.
>>      >
>>      > Notice that we got to the FPGA before Folding at Home!
>>      >
>>      > On 11/15/06, * gmeurice at dice.ucl.ac.be
>>     <mailto:gmeurice at dice.ucl.ac.be> <mailto:gmeurice at dice.ucl.ac.be
>>     <mailto:gmeurice at dice.ucl.ac.be>>*
>>      > <gmeurice at dice.ucl.ac.be <mailto:gmeurice at dice.ucl.ac.be>
>>     <mailto:gmeurice at dice.ucl.ac.be <mailto:gmeurice at dice.ucl.ac.be>>>
>>     wrote:
>>      >
>>      >     Bonjour,
>>      >
>>      >     Tuesday, November 14, 2006, 8:41:25 PM, you wrote:
>>      >
>>      >     JLB> Hi Guerric,
>>      >
>>      >     JLB> Any chance I can get you go target your design to an
>>      >     XCV2000E-6BG560C
>>      >     JLB> and tell me if it fits and what the clock rate estimate
> is?
>>      >
>>      >     JLB> It's just a data point for me to compare two year old
>>     data to
>>      >     the XCV4LX
>>      >     JLB> numbers.
>>      >
>>      >     JLB> Thanks,
>>      >     JLB> John
>>      >
>>      >     Ok, I can do that.
>>      >     The design will need 4 times the number of bRAMs compared
>>     with the
>>      >     Virtex4 design: 16-bit data width and no "read before write"
>>     mode.
>>      >
>>      >     With this kind of RAMs, a register on the B signal of the
>>     KeySchedule
>>      >     bloc could be saved using the fact that input is mirrored to
> the
>>      >     output of the bRAM while writing. I currently don't plan to
>>     make this
>>      >     optimization. (this would mean a saving of 26*3 *32/2 = 1250
>>     Slices).
>>      >     Whatever, it is probably bad from a place&route point of view.
>>      >
>>      >     I will test the full design with the new long shift register
>>     and will
>>      >     provides the implementation results.
>>      >
>>      >     --
>>      >     Guerric
>>      >
>>      >
>>      >     _______________________________________________
>>      >     Hardware mailing list
>>      >     Hardware at lists.distributed.net
>>     <mailto:Hardware at lists.distributed.net>
>>     <mailto:Hardware at lists.distributed.net
>>     <mailto:Hardware at lists.distributed.net> >
>>      >     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 at lists.distributed.net
>>     <mailto:Hardware at lists.distributed.net>
>>      > http://lists.distributed.net/mailman/listinfo/hardware
>>     <http://lists.distributed.net/mailman/listinfo/hardware>
>>     _______________________________________________
>>     Hardware mailing list
>>     Hardware at lists.distributed.net <mailto:Hardware at lists.distributed.net>
>>     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 at lists.distributed.net
>> http://lists.distributed.net/mailman/listinfo/hardware
> _______________________________________________
> Hardware mailing list
> Hardware at lists.distributed.net
> http://lists.distributed.net/mailman/listinfo/hardware
> 
> _______________________________________________
> Hardware mailing list
> Hardware at lists.distributed.net
> http://lists.distributed.net/mailman/listinfo/hardware
> 
> 

-- 
Nathan Klassen
Graduate Student: Political Science
Research Assistant: CPRN, SPHERU
CPHR Training Fellow
University of Regina
Regina, SK, Canada  S4S 0A2
P: (306) 337-2438 F: (306) 585-5694
E-Mail: klassenn at uregina.ca
www.cphr.ca; www.spheru.ca; www.cprn.ca


More information about the Hardware mailing list