Re: DRC has announced its newest FPGA that drops into AMD's Socket 940

On Fri, 28 Apr 2006 15:55:32 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>tomstdenis,
>
>http://www.xilinx.com/bvdocs/ipcenter/data_sheet/Helion_Standard_AES_AllianceCORE_data_sheet.pdf
>
>Shows some of the claimed clock rates for their AES encrypt/decrypt IP
>core. 257 MHz (V2 Pro) to 252 MHz (V4). Throughput in b/s is ~ 2 to 3
>X the clock rate (per this datasheet). Other cores run just shy of 200 MHz.
>
>Other data from this same vendor makes claims of up to 20 Gbs for
>throughput of their 'fast' FPGA based AES encryptors and decryptors.
>
>At one time we made a 10 Gbs decryptor to prove that distributing full
>resolution theater real time movies could be done with one FPGA in the
>'projector.' This prevents piracy by decrypting the movie at the
>projector itself (at no time is the full digital information available
>for copying).
>
>This was back in the Virtex II days, so the 20 Gbs claim is perfectly
>reasonable for V4 today (IMO).

20Gb/s was perfectly reasonable for V2P a few years ago.

I can't tell you how I know that :)

Allan

>
>There are a number of other IP vendors with encryptors and decryptors
>for our FPGAs.
>
>http://xgoogle.xilinx.com/search?output=xml_no_dtd&ie=UTF-8&oe=UTF-8&client=iplocator&proxystylesheet=iplocator&site=IPLocator&filter=0&_ResultsView=Standard&num=25&q=aes&as_q=&getfields=*&newSearch=http://www.xilinx.com/xlnx/xebiz/search/ipsrch.jsp&formAction=http://www.xilinx.com/cgi-bin/search/iplocator.pl&IPCategory=&IPSubcategory=&sGlobalNavPick=&sSecondaryNavPick=&requiredfields=IPProducts&partialfields=
>or
>http://tinyurl.com/hajhj
>
>Austin
>
>tomstdenis@gmail.com wrote:
>
>> Paul Rubin wrote:
>>
>>>tomstdenis@gmail.com writes:
>>>
>>>>The typical AES core takes ~14 cycles to encrypt but in FPGAs normally
>>>>run at most at a couple hundred MHz at most [usually topping out
>>>>between 100 and 200Mhz at most]. 200Mhz is 13 times less than 2.6Ghz
>>>>which is equivalent to 182 cycles at 2.6Ghz. This is less than the 256
>>>>cycles that the Opteron takes but only marginally so.
>>>
>>>I'd think if you're going to use such an expensive and exotic approach
>>>at all, you'd pipeline it to get one AES operation per cycle, maybe
>>>even more than one if you're doing something like EAX mode, or CTR
>>>mode ona large block in parallel.
>>
>>
>> Even with pipelining you're still on a fairly limited bus. At best you
>> top out at whatever the bus between the two actually is. Keep in mind
>> this is an FPGA and not ASIC. So chances are it won't clock that high
>> anyways. My 200Mhz quote is just a really really optimistic quote.
>>>>From what I recall from my past job you'd be lucky to get something
>> complicated like a PDU clocking higher than PCI freq [33Mhz]. So while
>> you could get an AES core ~100Mhz it would only be doing CTR mode at
>> most.
>>
>> Block ciphers are not where this will shine. Specially when the other
>> processor is an Opteron.
>>
>> The trick to making good use of something like an FPGA isn't serial
>> speed. Even if you designed a custom RISC ALU on the FPGA it'd clock
>> probably around 50Mhz. Even with the best ISA you can craft for it the
>> Opteron could EMULATE the thing faster than you could run it. Where
>> the FPGA will shine is for tasks with a LOT of parallel computation.
>> Think like 16 FPU pipelines or a single cycle GF(2) multiplier, etc,
>> etc, etc.
>>
>> Other tasks where this would shine would be custom DSP filters, e.g.
>> offload MPEG work. A FIR or IIR filter of significant delay [e.g.
>> accuracy] could be constructed in a pipeline to get 1 sample/cycle at
>> decent clock rates.
>>
>> Tom
>>
Received on Mon May 1 02:05:56 2006