4 ms·

I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to

I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible. Not an EE so I’m just dumping my thoughts.

dragontamer 7y ago
FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive (https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-A64G-PQ-G/122-2251-ND/9645682& https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.
- monocasa 7y ago
  DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.
  - dragontamer 7y ago
    > DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice. Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice. However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.
    - monocasa 7y ago
      Your original post is making it sound like FPGAs are switching from LUTs to DSP slices in the general case, which is blatantly not true. Yeah, it uses less resources to use a DSP slice instead of synthesizing a multiplier, bit that's because a DSP slice is just an 18x18 MAC. It's not replacing LUTs for general logic.
      - deleted 7y ago
        [deleted]
      - dragontamer 7y ago
        It wasn't my intent to say that FPGAs were switching away from LUTs in general. But I expect that FPGAs of the datacenter to be more-and-more DSP-based into the future. Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common? They're all giant matrix-multiplication problems at their core... fundamentally built up from the multiply-and-accumulate primitive. EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.
        monocasa 7y ago
        Super computers and data centers are two different things with markedly different requirements. Also, deep learning isn't a great fit for FPGAs anyway. There's dedicated silicon that does a better job if you're looking for matrix multiplies per watt. Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.
        dragontamer 7y ago
  - snagglegaggle 7y ago
    A lot of the inefficiency of FPGAs is signal routing. If you are very likely to implement X, Y, or Z, then it may just be more economical to put those into the FPGA as discrete circuits. At best maybe you can break them apart into common elements and provide those. There really isn't much need for LUTs any more, barring some fundamental change in data processing.
    - monocasa 7y ago
      That doesn't really follow given that LUT count has been increasing with Moore's law.
      - snagglegaggle 7y ago
        I see your point, but I think that is because of a lack of commitment to higher integration functional blocks. A lot of work done on a FPGA is very regular. I suppose LUTs could be the best way to do create the glue logic that basically amounts to signal routing and synchronization, but it seems unlikely.
        dragontamer 7y ago
        I'm not going to be surprised if FPGAs of the future start building in on-chip non-blocking CLOS-networks to more efficiently route messages across the chip. https://en.wikipedia.org/wiki/Clos_network https://en.wikipedia.org/wiki/Clos_network Dedicated-hardware that serves a purpose. Sure, you can build a CLOS-network out of LUTs, but it'd be more efficient if you made dedicated hardware for it instead.
        monocasa 7y ago
        I wouldn't be surprised if some do that under the hood already. The cadence hardware emulators for sure do, but they're not quite FPGAs.
        monocasa 7y ago
        If you can get by with higher level functional blocks sitting off of a network on chip, you go the direction of a modern SoC. The neat games you can play with routing those NoC packets around are close to what you're talking about.
segfaultbuserr 7y ago
One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx), > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA. Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522 https://news.ycombinator.com/item?id=21522522 I'm not an EE, just my 0.02 USD.
- abjKT26nO8 7y ago
  > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. I.e. ... I can print it? Good.

dragontamer 7y ago

FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive (https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-A64G-PQ-G/122-2251-ND/9645682& https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.

monocasa 7y ago
DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.
- dragontamer 7y ago
  > DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice. Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice. However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.
  - monocasa 7y ago
    Your original post is making it sound like FPGAs are switching from LUTs to DSP slices in the general case, which is blatantly not true. Yeah, it uses less resources to use a DSP slice instead of synthesizing a multiplier, bit that's because a DSP slice is just an 18x18 MAC. It's not replacing LUTs for general logic.
    - deleted 7y ago
      [deleted]
    - dragontamer 7y ago
      It wasn't my intent to say that FPGAs were switching away from LUTs in general. But I expect that FPGAs of the datacenter to be more-and-more DSP-based into the future. Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common? They're all giant matrix-multiplication problems at their core... fundamentally built up from the multiply-and-accumulate primitive. EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.
      - monocasa 7y ago
        Super computers and data centers are two different things with markedly different requirements. Also, deep learning isn't a great fit for FPGAs anyway. There's dedicated silicon that does a better job if you're looking for matrix multiplies per watt. Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.
        dragontamer 7y ago
- snagglegaggle 7y ago
  A lot of the inefficiency of FPGAs is signal routing. If you are very likely to implement X, Y, or Z, then it may just be more economical to put those into the FPGA as discrete circuits. At best maybe you can break them apart into common elements and provide those. There really isn't much need for LUTs any more, barring some fundamental change in data processing.
  - monocasa 7y ago
    That doesn't really follow given that LUT count has been increasing with Moore's law.
    - snagglegaggle 7y ago
      I see your point, but I think that is because of a lack of commitment to higher integration functional blocks. A lot of work done on a FPGA is very regular. I suppose LUTs could be the best way to do create the glue logic that basically amounts to signal routing and synchronization, but it seems unlikely.
      - dragontamer 7y ago
        I'm not going to be surprised if FPGAs of the future start building in on-chip non-blocking CLOS-networks to more efficiently route messages across the chip. https://en.wikipedia.org/wiki/Clos_network https://en.wikipedia.org/wiki/Clos_network Dedicated-hardware that serves a purpose. Sure, you can build a CLOS-network out of LUTs, but it'd be more efficient if you made dedicated hardware for it instead.
        monocasa 7y ago
        I wouldn't be surprised if some do that under the hood already. The cadence hardware emulators for sure do, but they're not quite FPGAs.
      - monocasa 7y ago
        If you can get by with higher level functional blocks sitting off of a network on chip, you go the direction of a modern SoC. The neat games you can play with routing those NoC packets around are close to what you're talking about.

segfaultbuserr 7y ago

One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx), > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA. Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522 https://news.ycombinator.com/item?id=21522522 I'm not an EE, just my 0.02 USD.

abjKT26nO8 7y ago
> By using this software, you agree not to: [...] display the object code of the Software on any computer screen. I.e. ... I can print it? Good.