4 ms·

I don't know much about the ins-and-outs of the FPGA ecosystem -- can you explain why you think this kind of collaboration would be impossible? Is it a technica

I don't know much about the ins-and-outs of the FPGA ecosystem -- can you explain why you think this kind of collaboration would be impossible? Is it a technical roadblock, a philosophical difference of opinion, a business decision, etc?

PaulHoule 3y ago
My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. FPGA vendors will also justify inertia in that current FPGA users don’t seem to be deterred by the bad tools because of the economics of their business. Some think a lot of hobby users would try FPGA if the toolset was easier to pick up but there are not enough of those folks to keep Radio Shack or even Fry’s alive and they will be buying $5-$150 parts, not the much more powerful $10,000-$100,000 parts.
- JoshTriplett 3y ago
  > My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. This has been the persistent argument for many years from companies who say they can't release Open Source graphics drivers. > FPGA vendors will also justify inertia in that current FPGA users don’t seem to be deterred by the bad tools because of the economics of their business. Want hundreds as times as many FPGA users? Make it easy for an FPGA to be used for transparent acceleration, by making it easy for Open Source libraries to build and ship FPGA bitstreams that serve as accelerators for their data handling. Imagine if compression libraries, databases, and many other kinds of libraries could transparently take advantage of an FPGA if available to process data many times faster. Then there'd be a benefit to shipping an FPGA in many servers, and many client systems as well.
  - MrCottenBall 3y ago
    I don't think that even with accessible tools there is going to be hundreds of times more users. At the end of the day, they are niche products with niche uses. The average random person isn't going out of their way to make accelerators or some kind of pipeline tool or circuit to do something random that couldn't just easily be achieved with a micro controller or Arduino. Those that are willing to go out of their way to design a custom circuit or something else on an FPGA are in my opinion the type already dedicated enough or driven enough to not be deterred by crappy tools. The work you do on FPGAs is already a filter enough so that I don't think anyone is getting passed that and then giving up because the tools suck.
    - UncleOxidant 3y ago
      > The work you do on FPGAs is already a filter enough so that I don't think anyone is getting passed that and then giving up because the tools suck. About 10 years ago I was doing some FPGA development in a startup. We were using Vivado. It seemed like we spent about 30% of our time working around Vivado bugs. I come from a hardware background originally and then got into software development (EDA tools) later on. After the startup gig ended I could've gone more in the direction of FPGA development. I decided not to because the tools suck and life is too short to deal with that day in and day out. And it's not simply that the FPGA vendor tools are some of the buggiest software known to humankind, it's that the FPGA vendors don't care to make them better.
    - nerpderp82 3y ago
      I think you are looking at it from the wrong perspective. It doesn't take 100x the devs to make FPGA compelling on the desktop or the server. Just like bespoke accelerators in Apple Silicon are used behind a library, so too will the accelerators implemented via FPGAs. The program itself can be copied a billion times. Your argument can be made for GPUs as well, the users (end users) aren't the ones writing the shaders, but GPUs are used my hundreds of millions of people.
    - JoshTriplett 3y ago
      You don't need a massive number of developers. You need a small number of developers contributing changes to popular libraries that are used by a huge number of people.
  - EMIRELADERO 3y ago
    > This has been the persistent argument for many years from companies who say they can't release Open Source graphics drivers. What? How can any company claim that with the patent thing at play? Wouldn't that just be admitting they're violating patents, therefore making the closed-sourceness reason moot in the first place? Moreover, wouldn't any sufficiently-interested patentholder just reverse-engineer the compiled binary and arrive to the supposed infringment on their own?
    - mschuster91 3y ago
      > Moreover, wouldn't any sufficiently-interested patentholder just reverse-engineer the compiled binary and arrive to the supposed infringment on their own? It's a MAD (mutually assured destruction) situation. You can rest assured that everyone knows about everyone else's rotting corpses in the storage locker... the first one to chicken out to the feds will get blasted to pieces just like everyone else. My personal opinion is that today's patent systems can go and die in a fire for all I care, right after copyright.
  - aseipp 3y ago
    The use cases you write about are mostly constrained by design, not software. Configuration of SRAM based FPGAs is rather slow because it requires a scan chain to program each logical element and shift config bits into, and doing it faster requires even more circuitry. You need to multiplex things onto the fabric in practice, you can't "context switch" AKA temporally multiplex very well, you have to spatially multiplex. But FPGAs are already area intensive; a k-LUT needs 2^k SRAM bits for the table, each bit being 6 transistors, on top of the scan chain to program it, and the registers and latches that go with the LUT in a typical logic element, and routing crossbars, and so on. Assuming K=6 then a single LUT would be like ~100x transistor overhead compared to a CMOS NAND gate (not a 1-to-1 comparison, just a ballpark). The SRAM requirements alone are problematic because it scales far, far worse than logic. If you're talking about a modern 7/5/3-nm wafer, area = money, and that's a shitload of money. So, what part of the system architecture do you even put the FPGA on? In the core complex? It can't be too big, then; your users are 99% better off with that area going to more cache and branch prediction. Put it on an older process and stuff it in the package? Packaging isn't free. Maybe just on the PCB? "Bump in the wire" to the NIC, or RAM, or storage? That limits the use, but an out-of-line design means there's less bandwidth available as input/outputs are shared. There are benefits and costs to them all and they all change the use cases and interface a bit. Now keep in mind you might have multiple parallel bitstreams you want to run. All of these choices impact how the software can interface with it and what capabilities it has. Example: Modern DDR5 has something like 64GB of bandwidth per channel; assuming your design is inline on the bus running at something like 500MHz, you'd need a 128-bit bus, per channel. That clock rate might require deep pipelining, further increasing area requirements, so you can't fit as much other stuff. Otherwise, you need a wider bus and to go slower, but wider buses often scale sub-linearly in terms of area and routing congestion; a 256-bit bus will be more than twice as expensive and difficult to route as a 128 bit one due to limited routing tracks, etc. So maybe you can hit that target, but then you're too routing congested, so you can't fit as many channels as you want in. Ergo, you need bigger/more FPGAs, or serious optimization and redesign. There's no immediate win. You need to explore/napkin math the design space to find the best solution on the pareto frontier, typically. Or just buy a FPGA that's massive overkill, AKA "buy a faster PC", the typical software programmer's solution. But it really isn't plug and play or anything close to that. It's similar to other niche things, like in-memory GPU databases. They are not held back by CUDA being proprietary. That fact does suck, but it's not really relevant in the grand scheme. They are held back by physical design dictating that parallel accelerators need loads of fast memory to feed the execution units, fast memory is super expensive and takes up a lot of space on the PCB resulting in a physical upper bound on density, and that the working set for such databases typically grows much, much faster than rate at which GPU memory performance/price drops. Past the point of no return (working set > VRAM), their advantages rapidly vanish. Their limitations are in the design, not the software. FPGAs taught me a lot about hardware/software design. I really like them and want more people to use them. I'm really excited there are fully FOSS flows, even if they have giant limitations. But they are pretty niche and have serious physical design factors to account for; I say that as someone who contributes to, uses, and loves the open-source tools for what they are, and even was lucky enough to play with them for work.
- EMIRELADERO 3y ago
  > My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. Assuming the patentholder had sufficient and warranted suspicions, wouldn't they initiate legal action and get the actual source/hardware design files through discovery anyway?
- 127361 3y ago
  There are existing reverse engineering efforts for AMD Xilinx devices: https://f4pga.org/ https://f4pga.org/ https://f4pga.readthedocs.io/projects/prjxray/en/latest/architecture/bitstream_format.html https://f4pga.readthedocs.io/projects/prjxray/en/latest/arch... https://github.com/f4pga/prjxray https://github.com/f4pga/prjxray https://github.com/epfl-vlsc/bitfiltrator https://github.com/epfl-vlsc/bitfiltrator
- UncleOxidant 3y ago
  > My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. Maybe. There certainly is a lot of "secret sauce" energy around the bitstream formats. Primarily I think they guard the bitstream format to help ensure vendor lockin. Imagine if there were open tools that could easily target FPGAs from multiple vendors so that users could choose the most cost effective solution. The FPGA vendors don't want that.
  - someguydave 3y ago
    Yep, FPGAs would become cheap commodities like DRAM
    - PaulHoule 3y ago
      No,an FPGA is always going to be a lot bigger than an ASIC that does the same thing not least because it the ASIC does not have to support programmability.
- msla 3y ago
  > if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. Because the word "subpoena" doesn't exist for any of these companies?
  - not2b 3y ago
    They won't issue a subpoena for a fishing expedition, there has to be at least some evidence. However, I don't think that this is a real issue, as competitors and the most skilled customers already mostly know how the devices work. Also, both Xilinx (AMD) and Altera (Intel for now, but looks like the might spin it out) have so many patents that it's probably mutually assured destruction and a huge gamble if either sues the other. I think they just prefer having the tools proprietary, not just to lock the customers in (though they like that) but also to keep away from the hairy corners (avoid defects in the hardware design that could produce bad results or fry the chips).
- mips_r4300i 3y ago
  You are correct in your points, I'd just like to add some more info. The bitstream format is an obstacle but can be reversed. It's already been done for the Xilinx 7 series, lattice ecp5, and others. However, that does NOT solve the actual main problem - timing models. Timing models are huge databases hundreds of megabytes for a single FPGA that provides exact routing delays and propagation delays for groups of functional gates in the fabric. They are developed over months of painstaking analysis, debugging and tooling by the vendor. Timing models are what let's you say "please make this IP run at 166mhz" and the fitter knows exactly how hard to work placing and connecting LUTs so that is possible. Then, the timing analyzer will check the maximum frequency of that clock domain and ensure, using the timing models, that the specified frequency can be reached at all 4 process corners (PVT). A typical design will have usually anywhere from 5 to 30 clock domains. So if you have no support for the timing model, you effectively are not able to ever optimize your fitting process, and you have no idea if your FPGA will have its state machines explode when it gets a bit warmer than ambient.

PaulHoule 3y ago

My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. FPGA vendors will also justify inertia in that current FPGA users don’t seem to be deterred by the bad tools because of the economics of their business. Some think a lot of hobby users would try FPGA if the toolset was easier to pick up but there are not enough of those folks to keep Radio Shack or even Fry’s alive and they will be buying $5-$150 parts, not the much more powerful $10,000-$100,000 parts.

JoshTriplett 3y ago
> My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. This has been the persistent argument for many years from companies who say they can't release Open Source graphics drivers. > FPGA vendors will also justify inertia in that current FPGA users don’t seem to be deterred by the bad tools because of the economics of their business. Want hundreds as times as many FPGA users? Make it easy for an FPGA to be used for transparent acceleration, by making it easy for Open Source libraries to build and ship FPGA bitstreams that serve as accelerators for their data handling. Imagine if compression libraries, databases, and many other kinds of libraries could transparently take advantage of an FPGA if available to process data many times faster. Then there'd be a benefit to shipping an FPGA in many servers, and many client systems as well.
- MrCottenBall 3y ago
  I don't think that even with accessible tools there is going to be hundreds of times more users. At the end of the day, they are niche products with niche uses. The average random person isn't going out of their way to make accelerators or some kind of pipeline tool or circuit to do something random that couldn't just easily be achieved with a micro controller or Arduino. Those that are willing to go out of their way to design a custom circuit or something else on an FPGA are in my opinion the type already dedicated enough or driven enough to not be deterred by crappy tools. The work you do on FPGAs is already a filter enough so that I don't think anyone is getting passed that and then giving up because the tools suck.
  - UncleOxidant 3y ago
    > The work you do on FPGAs is already a filter enough so that I don't think anyone is getting passed that and then giving up because the tools suck. About 10 years ago I was doing some FPGA development in a startup. We were using Vivado. It seemed like we spent about 30% of our time working around Vivado bugs. I come from a hardware background originally and then got into software development (EDA tools) later on. After the startup gig ended I could've gone more in the direction of FPGA development. I decided not to because the tools suck and life is too short to deal with that day in and day out. And it's not simply that the FPGA vendor tools are some of the buggiest software known to humankind, it's that the FPGA vendors don't care to make them better.
  - nerpderp82 3y ago
    I think you are looking at it from the wrong perspective. It doesn't take 100x the devs to make FPGA compelling on the desktop or the server. Just like bespoke accelerators in Apple Silicon are used behind a library, so too will the accelerators implemented via FPGAs. The program itself can be copied a billion times. Your argument can be made for GPUs as well, the users (end users) aren't the ones writing the shaders, but GPUs are used my hundreds of millions of people.
  - JoshTriplett 3y ago
    You don't need a massive number of developers. You need a small number of developers contributing changes to popular libraries that are used by a huge number of people.
- EMIRELADERO 3y ago
  > This has been the persistent argument for many years from companies who say they can't release Open Source graphics drivers. What? How can any company claim that with the patent thing at play? Wouldn't that just be admitting they're violating patents, therefore making the closed-sourceness reason moot in the first place? Moreover, wouldn't any sufficiently-interested patentholder just reverse-engineer the compiled binary and arrive to the supposed infringment on their own?
  - mschuster91 3y ago
    > Moreover, wouldn't any sufficiently-interested patentholder just reverse-engineer the compiled binary and arrive to the supposed infringment on their own? It's a MAD (mutually assured destruction) situation. You can rest assured that everyone knows about everyone else's rotting corpses in the storage locker... the first one to chicken out to the feds will get blasted to pieces just like everyone else. My personal opinion is that today's patent systems can go and die in a fire for all I care, right after copyright.
- aseipp 3y ago
  The use cases you write about are mostly constrained by design, not software. Configuration of SRAM based FPGAs is rather slow because it requires a scan chain to program each logical element and shift config bits into, and doing it faster requires even more circuitry. You need to multiplex things onto the fabric in practice, you can't "context switch" AKA temporally multiplex very well, you have to spatially multiplex. But FPGAs are already area intensive; a k-LUT needs 2^k SRAM bits for the table, each bit being 6 transistors, on top of the scan chain to program it, and the registers and latches that go with the LUT in a typical logic element, and routing crossbars, and so on. Assuming K=6 then a single LUT would be like ~100x transistor overhead compared to a CMOS NAND gate (not a 1-to-1 comparison, just a ballpark). The SRAM requirements alone are problematic because it scales far, far worse than logic. If you're talking about a modern 7/5/3-nm wafer, area = money, and that's a shitload of money. So, what part of the system architecture do you even put the FPGA on? In the core complex? It can't be too big, then; your users are 99% better off with that area going to more cache and branch prediction. Put it on an older process and stuff it in the package? Packaging isn't free. Maybe just on the PCB? "Bump in the wire" to the NIC, or RAM, or storage? That limits the use, but an out-of-line design means there's less bandwidth available as input/outputs are shared. There are benefits and costs to them all and they all change the use cases and interface a bit. Now keep in mind you might have multiple parallel bitstreams you want to run. All of these choices impact how the software can interface with it and what capabilities it has. Example: Modern DDR5 has something like 64GB of bandwidth per channel; assuming your design is inline on the bus running at something like 500MHz, you'd need a 128-bit bus, per channel. That clock rate might require deep pipelining, further increasing area requirements, so you can't fit as much other stuff. Otherwise, you need a wider bus and to go slower, but wider buses often scale sub-linearly in terms of area and routing congestion; a 256-bit bus will be more than twice as expensive and difficult to route as a 128 bit one due to limited routing tracks, etc. So maybe you can hit that target, but then you're too routing congested, so you can't fit as many channels as you want in. Ergo, you need bigger/more FPGAs, or serious optimization and redesign. There's no immediate win. You need to explore/napkin math the design space to find the best solution on the pareto frontier, typically. Or just buy a FPGA that's massive overkill, AKA "buy a faster PC", the typical software programmer's solution. But it really isn't plug and play or anything close to that. It's similar to other niche things, like in-memory GPU databases. They are not held back by CUDA being proprietary. That fact does suck, but it's not really relevant in the grand scheme. They are held back by physical design dictating that parallel accelerators need loads of fast memory to feed the execution units, fast memory is super expensive and takes up a lot of space on the PCB resulting in a physical upper bound on density, and that the working set for such databases typically grows much, much faster than rate at which GPU memory performance/price drops. Past the point of no return (working set > VRAM), their advantages rapidly vanish. Their limitations are in the design, not the software. FPGAs taught me a lot about hardware/software design. I really like them and want more people to use them. I'm really excited there are fully FOSS flows, even if they have giant limitations. But they are pretty niche and have serious physical design factors to account for; I say that as someone who contributes to, uses, and loves the open-source tools for what they are, and even was lucky enough to play with them for work.
EMIRELADERO 3y ago
> My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. Assuming the patentholder had sufficient and warranted suspicions, wouldn't they initiate legal action and get the actual source/hardware design files through discovery anyway?
127361 3y ago
There are existing reverse engineering efforts for AMD Xilinx devices: https://f4pga.org/ https://f4pga.org/ https://f4pga.readthedocs.io/projects/prjxray/en/latest/architecture/bitstream_format.html https://f4pga.readthedocs.io/projects/prjxray/en/latest/arch... https://github.com/f4pga/prjxray https://github.com/f4pga/prjxray https://github.com/epfl-vlsc/bitfiltrator https://github.com/epfl-vlsc/bitfiltrator
UncleOxidant 3y ago
> My guess: if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. Maybe. There certainly is a lot of "secret sauce" energy around the bitstream formats. Primarily I think they guard the bitstream format to help ensure vendor lockin. Imagine if there were open tools that could easily target FPGAs from multiple vendors so that users could choose the most cost effective solution. The FPGA vendors don't want that.
- someguydave 3y ago
  Yep, FPGAs would become cheap commodities like DRAM
  - PaulHoule 3y ago
    No,an FPGA is always going to be a lot bigger than an ASIC that does the same thing not least because it the ASIC does not have to support programmability.
msla 3y ago
> if the bitstream format was documented competitors would know how the device works and be able to prove their patents are being violated. Because the word "subpoena" doesn't exist for any of these companies?
- not2b 3y ago
  They won't issue a subpoena for a fishing expedition, there has to be at least some evidence. However, I don't think that this is a real issue, as competitors and the most skilled customers already mostly know how the devices work. Also, both Xilinx (AMD) and Altera (Intel for now, but looks like the might spin it out) have so many patents that it's probably mutually assured destruction and a huge gamble if either sues the other. I think they just prefer having the tools proprietary, not just to lock the customers in (though they like that) but also to keep away from the hairy corners (avoid defects in the hardware design that could produce bad results or fry the chips).
mips_r4300i 3y ago
You are correct in your points, I'd just like to add some more info. The bitstream format is an obstacle but can be reversed. It's already been done for the Xilinx 7 series, lattice ecp5, and others. However, that does NOT solve the actual main problem - timing models. Timing models are huge databases hundreds of megabytes for a single FPGA that provides exact routing delays and propagation delays for groups of functional gates in the fabric. They are developed over months of painstaking analysis, debugging and tooling by the vendor. Timing models are what let's you say "please make this IP run at 166mhz" and the fitter knows exactly how hard to work placing and connecting LUTs so that is possible. Then, the timing analyzer will check the maximum frequency of that clock domain and ensure, using the timing models, that the specified frequency can be reached at all 4 process corners (PVT). A typical design will have usually anywhere from 5 to 30 clock domains. So if you have no support for the timing model, you effectively are not able to ever optimize your fitting process, and you have no idea if your FPGA will have its state machines explode when it gets a bit warmer than ambient.