6 ms·
I hope AMD sees the light and helps F4FPGA develop a more complete open source toolchain for their FGPAs (https://f4pga.org https://f4pga.org). With this subsys
by buildbot 3y ago
I hope AMD sees the light and helps F4FPGA develop a more complete open source toolchain for their FGPAs (https://f4pga.org https://f4pga.org). With this subsystem and an open source compilation flow, FGPA experiments would be way easier.
- UncleOxidant 3y agoUnfortunately this will never happen.
- hwbehrens 3y agoI 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 agoMy 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 agoI 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 agoI 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 agoYou 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> 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 agoThere 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 agoYep, FPGAs would become cheap commodities like DRAM
- PaulHoule 3y agoNo,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 agoThey 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 agoYou 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.