How many 32-bit RISC CPUs fit in an FPGA? Now vs. 1995?

Technology sucks :(

Another likely issue with FPGAs is that for everything but raw compute they still need support circuitry (physical I/O ports, memory interfaces, etc) that are different for every app but not really "reconfigurable" in the same sense as the FPGA fabric.

Finally, I'd wonder if reconfiguration time is part of the problem - until relatively recently, reconfiguring an FPGA was all-or-nothing and could take multiple milliseconds. Not a big deal when configuring a device once on boot, but serious headwind when trying to context-switch between different jobs that need FPGA assistance.

I believe there are 4 reasons why GPUs have taken off conventionally as compared to FPGAs:

1. Last I checked, the FPGA vendors will not open their toolchains up, and not even document the bitstream formats. They will claim NDA, proprietary, etc. This has the massive side effect that you are stuck with their bloated, slow, crappy toolchains. If this were open, I guarantee hackers would be inventing all kinds of interesting ways to convert their software into FPGA bits.

2. FPGAs are VERY hard to write and debug. You have to write your design in an HDL language (either VHDL or Verilog), and you have to use a software simulator to prototype the design on first (and of course these tools are either quite pricy or if free they are usually limited or hard to use). Then you can synthesize the design and download it into the FPGA for running.

The next problem is debugging your design. The entire internal state of the FPGA is only accessible through slow scan, unless you dedicate a portion of your design to "monitors", which tap the traffic and store their values into internal RAMs. So you may have to respin the design just to get more monitors to debug where the issue is.

3. FPGA compilation is SLOW. When I used them professionally a few years ago, a Virtex5 could take multiple hours to resynthesize/place & route a medium-sized design. I believe that Virtex7 they are advertising could take over a day to respin if you change your design.

4. Most new machines already have a built-in graphics with a GPU that can be utilized as a general-purpose GPU. No one ships FPGAs in any conventional computer.

I think one of the main reason is programming the FPGA is not easy, the tools needed for FPGA development are all proprietary. Every FPGA has different way to program it.

I actualy have 2 FPGA-based devices that I use daily - polyphonic analog synthesizers, to be specific. Manufacturers are tight-lipped about how they're using the FPGAs, but it appears to be for ultra-rapid reconfiguration of analog circuit topologies without the load time delays that result from a traditional microcontroller > D/A converter arrangement. There are also field-programmable analog arrays on the market, but I have yet to see one in a commercial product and it seems like they have some way to go before being economical for audio synthesis applications.

I love FPGAs although I don't know much about how to et started with programming them. There is an ASIC coming out of patent in a year or so which I'd like to re-implement in an FPGA package, and I've thought about reaching out to the original architect who lives nearby and is a friendly fellow. I'm not sure how feasible this is, though.

A long time ago computers sometimes came with DSPs dedicated to Photoshop-like programs. The GPU is a logical extension of that. The FPGA is something entirely different.

Maybe FPGA's are competitive in integer math, but that's a pretty small niche ,not big enough for a coprocessor.

http://www.kosagi.com/w/index.php?title=Novena_Main_Page

2) GPUs, being purpose-built and mass-marketed, are both much cheaper and much faster. Think of the Ford Fiesta ST vs. a Jeep Wrangler. The Jeep is simple & more reconfigurable, yet is slower and more expensive- for exactly those reasons!

3) GPUs and CPUs compliment eachother well. The only gap is heavily parallel branching code- GPUs are bad at if-statements, CPUs are bad at heavily parallel. But a branch predictor is the key to if-statements, and branch predictors are hard.

FPGAs are fundamentally a prototyping tool. Can you think of examples of prototyping tools that eventually broke into the main market, replacing the incumbent product?

CPU gives you speed in computation. Except for a custom ASIC, nothing can match a modern CPU in single thread speed.

GPUs gives you parallelism. You can get thousands of decent CPUs in cheap boards today.

IMHO FPGAs main advantages today are bandwidth and auditability. But neither are very important in most applications.

Consequently, FPGAs don't lend themselves to an uncontrolled explosion of innovation. Compare with GPUs and CPUs where open source compilers are available and anyone can have a crack at innovating, at whatever level they choose.

As an example, if you want to dynamically generate programming for a Xilinx FPGA, you need to incorporate Xilinx's binary only PPR program somewhere into the flow. That acts as a ball and chain around the leg of reconfigurable computing, impeding its development and adoption.

[1] http://www.ifixit.com/Teardown/MacBook+Pro+15-Inch+Unibody+M...

How do you balance the need for high-performance communication between the FPGA and the rest of the computer with the inherent inability to trust whatever configuration has been loaded into the FPGA? Software security is hard enough without infinitely reconfigurable devices lurking inside our machines.

How does a possible FPGA configuration work optimally across a wide variety of FPGAs (which can have various "built-in", non-reconfigurable components) and sizes that can only be determined at "flashtime"?

What exactly do regular users need an FPGA for that isn't already handled by dedicated silicon with much greater performance and much less power usage than an FPGA would?

EDIT: I'd like an FPGA card for my PC just for running FPGA "emulators," because you can recreate a SNES or whatever in a tiny fraction of the gates that you need to make a CPU capable of emulating it with cycle accuracy at full speed. I seriously doubt there's much demand for that, though: if you're going to go to the trouble of buying special hardware for emulation, you might as well just buy the console and a flash cart.

Without the annual growth of transistor density, the second best avenue to gain performance will probably be specialization, and reconfigurable specialized hardware looks more attractive than fixed one.

FPGA's are horrendously inefficient, space and power-wise, for many tasks. Much of the core is taken up by the programmable routing between different components, and generally most components will be not fully utilized (such as LUTs and RAM).

Yes, the Virtex-7 (a VERY EXPENSIVE fpga) can hold 1000 very simple 32 bit cores.... but a top end NVIDIA GPU has 2688 CUDA cores. While not entirely independent, these CUDA cores have far deeper pipelines and far superior ALU's to the one in the article. If your software fits the programming model, GPUs will handily beat a FPGA.

FPGA's are great for prototyping ASICs, and cases where timing is of critical importance - try implementing a VGA video generator on a CPU. Basically everywhere an FPGA would excel, an ASIC excels more, but FPGAs are great for low volume and or specialty hardware where a GPU is not good at accelerating the task at hand.

The coding was hard and performed below expectation. The only customers that benefited were military/intelligence agencies who were using outdated techniques such as filtering in the Fourier basis.

The problem was data-transfer compounded by inflexible code generation. The data still needed to travel from RAM which meant that even without computation you couldn't get over a 50% increase in performance. It would need to be send back for more complex processing.

So, your vision of general-computation-in-silicon has occurred, just static, not dynamic.

1. They are already there in commodity HW.

2. GPU vendors make money with their hardware; they need not extort developers for a development environment like FPGA vendors think they have to do. Therefore, development for GPUs has a lower barrier of entry.

My naive best guess is that when CPUs stop getting much faster the next wave of innovation will be on bus speeds. But I'm not a chip guy so perhaps my view of the problem is overblown, but I'm very interested in learning more about this from others.

http://www.fpgacpu.org/log/sep00.html#000919