One just needs a wafer scale FPGA.

I suspect that if you asked a microelectronics engineer about that he would disagree. An FPGA has too many things not needed; there will be leakage and other nasty effects constraining frequency. And wafer scale? Signals need time to move. You can't just scale things up like that. Those are my hunches anyway - we'd need a specialist to say more.

Yes, there would be huge practicality issues with a "wafer-scale" FPGA -- aside from propagation delays, as you note, the chip would have horrible manufacturing yield, because any defect anywhere on the wafer would produce a defective chip. (In contrast, when a wafer has a bunch of tiny chips, a given defect only takes out one small chip, and you still have the other N-1 to use.) Ultimately this drives up cost to the end-user.

Fab equipment also has limits in how big a single chip can be due to "reticle limits", i.e., the size of a single mask exposure, and a chip has to be a single exposure (per layer).

The CAD software (place+route) might actually be a limiter here too. Even if, in theory, you had an FPGA with enough logic blocks to match a modern GPU's raw gate count (i.e., circuit size), an FPGA is just a sea of identical configurable blocks and parts of the circuit are assigned to the blocks and connected with wires using something like simulated annealing. This is why FPGA place+route takes so long. In contrast, a custom chip can put exactly the right gates and wires at exactly the right places, and especially for something like a GPU or a large cache where there are lots of repeated elements, this human involvement makes things much more tractable. (It's also why e.g. the caches on a modern CPU die look so pretty, like a big grid of farms or something -- an FPGA-synthesized CPU cache would look nothing like that, and take much more space!)

All of that said -- from an academic point of view, this GPGPU core is an impressive piece of work, especially given that it includes an LLVM backend!

GPUs run at a pretty low clock rate anyway (600Mhz-1100Mhz), should be able to get 300-400Mhz out of an FPGA, the main issue is interfacing with the GDDR memory, if you can.

There were some pushes for wafer scale stuff in the 80s [0], I think we are better suited from an algorithms, EDA and architecture standpoint now to actually make it work. A GPU is actually pretty good test bed and eventually GPU and FPGA functionality will merge into a single programmable compute fabric.

Yield on a wafer scale FPGA could actually be much better than a special purpose chip. The faulty logic elements / LUTs could just be marked as bad and not used.

[0] http://en.wikipedia.org/wiki/Wafer-scale_integration

> GPUs run at a pretty low clock rate anyway (600Mhz-1100Mhz), should be able to get 300-400Mhz out of an FPGA

An ASIC (GPUs are ASICs) running at 300 MHz can do a lot more per cycle than an FPGA at the same technology node running at the same frequency. A lot. Think order-of-magnitude more.

> The faulty logic elements / LUTs could just be marked as bad and not used.

This will screw up your timing, unless you reserve more setup slack (which in turn hurts the achievable performance).

I've got memories of a lab actually doing a wafer scale FPGA in the mid 90's. The reference escapes me, but if I can find it I'll post it. As you suggested, they preserved the yield by routing around defects.

---

Edit: Or it might have been a PGA, rather than an FPGA.

'just'?

FPGA's for ASIC simulation of larger chips are typically arrays of FPGAs rather than single chips.

You get stuff like this:

http://chipdesignmag.com/images/idesign/fpga/figure1.jpg

I'm not aware of anybody shipping a wafer scale FPGA.

It was an ambitious just.

A like 'mere' in 'a mere matter of programming' :)

Now I get it. Sorry for the misunderstanding, appreciate the expansion.