FPGAs will have very hard time to be as fast as "dedicated" CPUs, frequency-wise. The FPGA structures have to be too generic, and are much bigger than specialized structures of the CPUs, so they have higher capacity, which limits the maximum achievable switching frequency. The length of the wiring between the structures together with the lazy speed of light plays its role as well. However, the FPGA structure allows parallelizing of processing tasks, which can in some cases neatly beat the sequential CPUs. There are FPGAs with on-chip RISC CPU cores, allowing reaping the benefits of both architectures in a single chip. On Sat, 5 Mar 2005, Tyler Durden wrote:

Well, what would you call a network processor? An FPGA or a CPU? I think of it as somewhere in between, given credence to the FPGA statement below.

-TD

...

From: "Major Variola (ret)" To: "cypherpunks@al-qaeda.net" Subject: Re: SHA1 broken? Date: Sat, 05 Mar 2005 06:51:24 -0800

At 09:23 PM 2/19/05 +0000, Dave Howe wrote:

...

I am unaware of any massive improvement (certainly to the scale of the comparable improvement in CPUs) in FPGAs, and the ones I looked at a a few days ago while researching this question seemed to have pretty

FPGAs scale with tech the same as CPUs, however CPUs contain a lot more design info (complexity). But FPGAs since '98 have gotten denser (Moore's observation), pioneering Cu wiring, smaller features, etc.

Well, maybe I misunderstand your statement here, but in Telecom most heavy iron has plenty of FPGAs, and as far as I understand it, they more or less have to. -TD

From: "Riad S. Wahby" To: Cypherpunks Subject: Re: SHA1 broken? Date: Mon, 7 Mar 2005 17:57:50 -0600

Thomas Shaddack wrote:

...

There are FPGAs with on-chip RISC CPU cores, allowing reaping the benefits of both architectures in a single chip.

FPGAs are mostly useful for prototyping. Once you've decided on a design, there's no point in realizing it in a reprogrammable environment. Synthesize it, time it carefully, and run it as fast as your process allows.

TSMC 0.13u just ain't that pricey any more.

-- Riad S. Wahby rsw@jfet.org

Ah. You meant as a principal in general. Of course the prevailing wisdom is to go from FPGAs to ASICs when you have heavy tasks. In Telecom equipment, however, there's a few issues that basically 'require' FPGAs. First, the standards change quite a bit, depending on which area you're in. For instance, RPR didn't really get settled until very recently. Second, your customers may ask for "more" or different kinds of functionality, so you may have a new release of firmware to address that. Putting the framing and/or PM on an FPGA while keeping the guts (eg, packet processing) on the main ASIC/processor allows you to swap out the trivial without a major heart transplant. In addition, there's probably the far more important issue of design cycle times. ASICs will take (at the very minimum) 18 months to create, and if you make a mistake early on and don't catch, you have to start all over again. For some fields that's just unacceptable. Then again, if you're looking for sheer, brute performance and design cycle times are not a limiting factor, ASICs are often the way to go. Even in a Variola Suitcase, however, I'd bet some of the trivial functions are off-loaded to an FPGA, though, for reasons above. -TD

From: "Riad S. Wahby" To: cypherpunks@al-qaeda.net Subject: Re: SHA1 broken? Date: Tue, 8 Mar 2005 13:26:48 -0600

Tyler Durden wrote:

...

Well, maybe I misunderstand your statement here, but in Telecom most heavy iron has plenty of FPGAs, and as far as I understand it, they more or less have to.

Have to in what sense? If they're constantly reconfiguring the FPGAs (new software revs, or some sort of evolutionary "learning" process--- the latter not likely in telecom, of course), sure, they have to be on reprogrammable structures.

If, on the other hand, you're building a custom hash cracking machine, you don't need to reconfigure your gates. You could design your parallelized SHA1 cracking machine and dump it onto a bunch of FPGAs, but if you really have unlimited resources you take the plunge into ASICs, at which point you can tighten your timing substantially.

-- Riad S. Wahby rsw@jfet.org