4 ms·

A k-LUT SRAM-based FPGA where k=6 is something like 100x more inefficient in terms of raw transistor count than the equivalent ASIC gates when I last did some n

by aseipp 4y ago

A k-LUT SRAM-based FPGA where k=6 is something like 100x more inefficient in terms of raw transistor count than the equivalent ASIC gates when I last did some napkin math (though there's a statistical element in practice when considering k-LUTs vs fixed netlists.) But the SRAM requirements scale 2^k with the LUT size, so the highest you get in practice today is 6-LUTs and 80% of vendors do 4-LUT. And then you need all the transistors for the scan chain to configure each bit, actual block RAM, fixed function DSPs, etc. Clocking them to really high frequencies is also difficult. They're mostly overpriced because the market is small and the only competitors in town can rob you; bulk buys from having costs 1/50th the list-price, per-device, isn't unusual. But the big problem isn't really the hardware. You can go create and simulate a robust design in a number of HDLs, there are all kinds of tools to do it now, though they aren't as fancy as proprietary ones. It's doable. But it's having a good software stack that matters. You can blow a billion dollars on a chip and still lose because of the software. Nvidia figured this out 10 years ago and everybody else is still playing catch up. And it takes an insane amounts of software engineering to make a good compute stack. That's why Nvidia is still on top. Luckily there are some efforts to help minimize this e.g. PyTorch-MLIR for ML users, though more general compute stack needs, such as accelerated BLAS or graph analytics libraries or OpenMPI, are all still "on you" to deliver. But if you stick your head in the sand about this very important point, you're going to have a bad time and waste a lot of money.

zozbot234 4y ago
A 100× transistor count would amount to basically 6 to 7 doublings of Moore's law. Or 10× in nm device lengths. So once the inherent difficulties of designing a chip for trailing-edge ASIC are addressed (with better free EDA tools and such) it seems that FPGA-based commercial products (as opposed to use of FPGAs for bespoke prototyping needs) should become quite uncompetitive. There's also structured ASIC, multi-project wafer, etc. design approaches that are sort of half-way, and might provide an interesting alternative as well. OTOH, FPGA's might also be more easily designed to integrate pre-built components like CPU cores, and the 100× rule wouldn't apply to such parts if used in an FPGA-based design.
- imtringued 4y ago
  100x transistor count is a big enough difference that you would want some sort of ALU and branching/FSM/loop unit arranged in an array with a few fpga elements on inputs and outputs. It sounds to me that the real problem is still that the ideal programming model hasn't been created yet. What would it look like? Compile a C function into an FPGA pipeline? A dataflow language where you explicitly define processes and their implementation? I mean imagine if you could take a mathematical formula, how would it translate into a series of additions, subtractions and multiplications? You could write it down in Fortran and then you would have a well defined and ordered tree of operations. Do we just translate that tree into hardware? Like, you have 100 instructions with no control flow and you just translate it into 100 ALUs? Does it make sense to reuse the ALUs and therefore have 100 instructions map to less than 100 ALUs? If we assume the above model, then there are specific requirements for the hardware. What if need more than one algorithm? Can I switch the implementation fast enough? Can the hardware have multiple programmed algorithms for the same ALUs? Programmable ALUs sound awfully close to what a CPU does but in theory you would just have a register file with say 16 different ALU configurations and the data you are sending through the ALUs is prefixed with a 4 bit opcode that tells the ALU which configuration to use. We are getting further and further away from what an FPGA does and closer to how CPUs work but we still have the concept of programming the hardware for specific algorithms. These are just random thoughts but they reveal that the idea of a pure FPGA is clearly not what the accelerator market needs.
imtringued 4y ago
>And it takes an insane amounts of software engineering to make a good compute stack That isn't actually true. It takes commitment to the platform. My AMD GPU from 2017 had its ROCm support dropped in 2021. Very nice. That sends a signal that ROCm isn't worth supporting by application developers. In other words, AMD decided that there are ROCm and gaming GPUs whereas with Nvidia there is no distinction.

by aseipp 4y ago

zozbot234 4y ago

A 100× transistor count would amount to basically 6 to 7 doublings of Moore's law. Or 10× in nm device lengths. So once the inherent difficulties of designing a chip for trailing-edge ASIC are addressed (with better free EDA tools and such) it seems that FPGA-based commercial products (as opposed to use of FPGAs for bespoke prototyping needs) should become quite uncompetitive. There's also structured ASIC, multi-project wafer, etc. design approaches that are sort of half-way, and might provide an interesting alternative as well. OTOH, FPGA's might also be more easily designed to integrate pre-built components like CPU cores, and the 100× rule wouldn't apply to such parts if used in an FPGA-based design.

imtringued 4y ago
100x transistor count is a big enough difference that you would want some sort of ALU and branching/FSM/loop unit arranged in an array with a few fpga elements on inputs and outputs. It sounds to me that the real problem is still that the ideal programming model hasn't been created yet. What would it look like? Compile a C function into an FPGA pipeline? A dataflow language where you explicitly define processes and their implementation? I mean imagine if you could take a mathematical formula, how would it translate into a series of additions, subtractions and multiplications? You could write it down in Fortran and then you would have a well defined and ordered tree of operations. Do we just translate that tree into hardware? Like, you have 100 instructions with no control flow and you just translate it into 100 ALUs? Does it make sense to reuse the ALUs and therefore have 100 instructions map to less than 100 ALUs? If we assume the above model, then there are specific requirements for the hardware. What if need more than one algorithm? Can I switch the implementation fast enough? Can the hardware have multiple programmed algorithms for the same ALUs? Programmable ALUs sound awfully close to what a CPU does but in theory you would just have a register file with say 16 different ALU configurations and the data you are sending through the ALUs is prefixed with a 4 bit opcode that tells the ALU which configuration to use. We are getting further and further away from what an FPGA does and closer to how CPUs work but we still have the concept of programming the hardware for specific algorithms. These are just random thoughts but they reveal that the idea of a pure FPGA is clearly not what the accelerator market needs.

imtringued 4y ago

>And it takes an insane amounts of software engineering to make a good compute stack That isn't actually true. It takes commitment to the platform. My AMD GPU from 2017 had its ROCm support dropped in 2021. Very nice. That sends a signal that ROCm isn't worth supporting by application developers. In other words, AMD decided that there are ROCm and gaming GPUs whereas with Nvidia there is no distinction.