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

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).

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:53 2006