4 ms·

> 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

> 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.

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.