8 ms·

Programmable logic seems like a space that could be disrupted with a company that has fully open-source tooling around its hardware along with great documentati

Programmable logic seems like a space that could be disrupted with a company that has fully open-source tooling around its hardware along with great documentation. FPGA tooling is in the dark ages compared to modern software development environments. If you found such a company I will be your customer and simp/shill/stan for life.

etaioinshrdlu 6y ago
There are a bunch of fully open FPGA designs on the first efabless shuttle run: https://efabless.com/open_mpw_shuttle_project_mpw_one https://efabless.com/open_mpw_shuttle_project_mpw_one
krasin 6y ago
Quick Logic is an FPGA manufacturer that recently started to offer chips & boards with a fully open source toolchain: https://www.quicklogic.com/tag/open-source-fpga/ https://www.quicklogic.com/tag/open-source-fpga/
- asddubs 6y ago
  AFAIK the iCE FPGAs also have open source tooling available
  - bri3d 6y ago
    Not company supported, though, just reversed and company-tolerated. The investment was made by brilliant people donating their personal time, not the company funding an initiative - big difference there. I think a truly "open" documentation and compilers model (like what AMD have been up to with their graphics cards) would still be a game-changer in the industry.
    - TomVDB 6y ago
      I honestly don't think opening up documentation would change a lot. The medium hard part of FPGA tooling is synthesis, and the truly hard part is high performance placement and routing with low run times. The competitive benefits of being good at that are huge, because it can literally mean the difference between choosing a component of one vendor vs the one of another. As a user, the tooling and the underlying HW architecture can be mostly treated as an inseparable blob: it's not as if you're going to design specifically for a particular FPGA logic element feature, you rely entirely on what the backend tool with do with it. If I were Intel or AMD, I'd be fine with opening up some documentation that helps users to a certain extent, but I'd never agree to an open backend model.
      - bri3d 6y ago
        With respect to opening the backend: it's also unlikely that your competitor is going to use your PnR against you, between patent encumbrance and backend silicon differences, no? This is the exact same argument as in graphics where AMD have done fine open-sourcing their compiler backends, nobody is going to cut-rate clone their silicon and NVidia are staying far, far away from any of the methods+processes there if they are smart. With that said, I don't understand the FPGA market well enough to know if open tooling would be an advantage competitively. With respect to opening documentation: I really do wonder. I don't know the market well enough. For a "we need an FPGA because we need XYZ to be fast and don't have the volume/$ to tape out," of course a good PnR and meeting timing is the #1 concern, and a savvy buyer would choose the best performing solution even if the software suite is brutal to use. But for "we need a PLD for some glue logic, it doesn't need to be 100% blazing fast, it needs to meet XYZ requirements," would a buyer choose a toolchain that worked better and let their engineers go to market faster, even if the PnR wasn't quite as efficient? In that case, opening up documentation and letting the open-source ecosystem build out support could be valuable. What would be telling here would be whether Lattice have seen a measurable sales impact from the reverse engineered open toolchain appearing for their parts. I cynically think that perhaps the idea is futile in this industry, but that's also what everyone thought about graphics and AMD went and did it anyway...
AlphaSite 6y ago
Considering AMDs software chops, I guess that won’t be coming from them.
- xbmcuser 6y ago
  I thought that was one of the reasons that they acquired Xilinx to improve the software side.
  - DoingIsLearning 6y ago
    That was my hope as well, I still dream of Xilinx or Intel deciding to 'LLVM' their toolchain down to bitstream, I keep looking with a lot of interest at Lattice and the Yosys project as it is maturing. These companies make money selling hardware, just open the tools and let people use what they want instead of forcing this 'visual programming' paradigm with half-baked IDEs on everyone. My worry with AMD is what will happen to the SoC chips that have actual ARM cores in the fabric (like the Zynq family)?
    - aseipp 6y ago
      Visual block diagram editors like the one in Vivado, Libero, etc are extremely useful and powerful in practice and an equivalent alternative for open source EDA design would be very welcome. And I'm a person who absolutely loathes Verilog, so it's not like I'm a purist or anything. If that's your representative example of your issues with proprietary FPGA software, I honestly don't think it's a very good one.
      - DoingIsLearning 6y ago
        > 'visual programming' paradigm with half-baked IDEs The paradigm is the least important, when it works, I don't know anyone in real world projects that didn't have to configure something manually through a tcl script because it was either not exposed in GUI or not working in GUI. My issue is not with 'visual programming' my issue is with the 'half-baked' part of the tools. There are too many multi year old bugs that go acknowledged by Xilinx. The VHDL2008 standard came out more than a decade ago and from memory it was only in 2019 that they supported it as a valid simulation file in Vivado. There a plethora of autogenerate/copied/cached files that add a ridiculous amount of friction to any attempt of sane version control. There is just too much complexity in what I assume is an attempt to hide the shoe-horned messiness of the tcl backend and 'prettifying' the GUI frontend.
deleted 6y ago
[deleted]
snvzz 6y ago
There's open source tooling for a bunch of FPGAs: QuickLogic EOS S3 (provided by QuickLogic) Lattice iCE40 (reversed, project icestorm) Lattice ECP5 (reversed, project trellis) Lattice Nexus (reversed, project oxide) Gowin GW1N (reversed, project apicula) Xilinx family 7 (reversed, project x-ray) With more on the works. Hopefully an AMD Xilinx will start contributing to the open source tooling themselves, as they do with CPU and GPU tooling.
rkangel 6y ago
I agree on the 'user friendliness' of FPGA tooling, but SW Engineers (myself including) often make the mistake of thinking an FPGA toolchain is like a software toolchain and therefore everything is equivalent. These are the two main reasons that FPGA toolchains aren't as open as compilers (I'm not saying they're good ones): * Processors have a defined interface ("instruction set") that you can implement a compiler for and have it keep working. The interaction between the FPGA tooling and the FPGA targeted it much more complicated. It's a bit like graphics card drivers and the hardware, where the line between the two is blurry and you have to consider them both together as the graphics system. This means that the 'cleverness' of the design is much more exposed to the toolchain and having that open source would give a way a lot to competitors * Synthesising FPGAs is a LOT harder and more complicated than compiling code (and compiling code is pretty hard). There are many stages in the pipeline involving synthesising the logic and laying it out on the target for best performance. To give an example, we upgraded our toolchain for a Xilinx FPGA and power consumption improved by 20% because they'd changed the ways that they segment clock domains and gate off stuff being used. Good performance in the tooling is a major differentiating factor that you might not want to give away.
- regularfry 6y ago
  That point about toolchain complexity just reminds me of where compilers were 20 years ago. You could get significant speed bumps because one vendor had an optimisation another didn't. That's probably still true for things like the intel compiler, for all I know. I do remember at one point doing computer vision stuff before NVidia ate the world that it wasn't uncommon to come across code that expected to have access to intel-compiled maths libraries to be able to run in real-time. The point is that the free toolchains got good enough that in general you don't need to care, and I think it's reasonable to expect the same dynamics to apply here.
  - pm215 6y ago
    It's still true for compilers -- for instance gcc 10 had a greater than 10% perf improvement for AArch64 targets compared to gcc 9 as a result of various optimisation work: https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/gcc-10-better-and-faster https://community.arm.com/developer/tools-software/tools/b/t...
jhallenworld 6y ago
I'm a bit skeptical on this one. Open tools may help, but for full vendor support you are going to have to use their tools. Also I wouldn't say that their tools are in the dark ages- most of the problems with their tools stem from modern software tool design. So for example, I find Vivado / SDK to be complex yes, but also much more pleasant to use than tool chains for simple micro-controllers. An example is the total mess that is software libraries delivered via STM32CubeMX (no part migration, libraries depend on custom BSPs vs. auto-generated code, good luck preserving your fixes if their auto-generated code has bugs). A reason that the Xilinx tools are big and complex is that they are following modern software tool practices (that I hate): it's a large Java-based tool that aims to hide the underlying relatively simple command line programs. Xilinx tools from the mid-90s are actually closer to what the open source FPGA tools look like today.
stelonix 6y ago
I somewhat agree, but I think the number 1 factor of low FPGA adoption is the absurd price. Put a good price tag like in GPUs and you have a new industry. Of course, there are issues with tooling too. Maybe there needs to be a simplified API, akin to OpenGL, that takes care of the boilerplate.
vmchale 6y ago
clash? I like their mailing list :) https://clash-lang.org/ https://clash-lang.org/
moistbar 6y ago
> FPGA tooling is in the dark ages compared to modern software development environments. Dear god is it ever. My fiancee, bless her, got me a Spartan 6 for Christmas one year. I never got around to using it because I couldn't find a download for the single, outdated version of (I think) Arduino Software it claimed it 100% required.
xyzzy21 6y ago
Absolutely! And the FPGAs need not even be as efficient in packing as Xilinx or Altera. The thing that always gets me: you are already charging for HW - that's the only real business model. The CAD tools 1) suck, 2) aren't going to be a major money maker, and 3) desparately need UI design and programming talent well beyond what ever gets applied today.

etaioinshrdlu 6y ago

There are a bunch of fully open FPGA designs on the first efabless shuttle run: https://efabless.com/open_mpw_shuttle_project_mpw_one https://efabless.com/open_mpw_shuttle_project_mpw_one

krasin 6y ago

Quick Logic is an FPGA manufacturer that recently started to offer chips & boards with a fully open source toolchain: https://www.quicklogic.com/tag/open-source-fpga/ https://www.quicklogic.com/tag/open-source-fpga/

asddubs 6y ago
AFAIK the iCE FPGAs also have open source tooling available
- bri3d 6y ago
  Not company supported, though, just reversed and company-tolerated. The investment was made by brilliant people donating their personal time, not the company funding an initiative - big difference there. I think a truly "open" documentation and compilers model (like what AMD have been up to with their graphics cards) would still be a game-changer in the industry.
  - TomVDB 6y ago
    I honestly don't think opening up documentation would change a lot. The medium hard part of FPGA tooling is synthesis, and the truly hard part is high performance placement and routing with low run times. The competitive benefits of being good at that are huge, because it can literally mean the difference between choosing a component of one vendor vs the one of another. As a user, the tooling and the underlying HW architecture can be mostly treated as an inseparable blob: it's not as if you're going to design specifically for a particular FPGA logic element feature, you rely entirely on what the backend tool with do with it. If I were Intel or AMD, I'd be fine with opening up some documentation that helps users to a certain extent, but I'd never agree to an open backend model.
    - bri3d 6y ago
      With respect to opening the backend: it's also unlikely that your competitor is going to use your PnR against you, between patent encumbrance and backend silicon differences, no? This is the exact same argument as in graphics where AMD have done fine open-sourcing their compiler backends, nobody is going to cut-rate clone their silicon and NVidia are staying far, far away from any of the methods+processes there if they are smart. With that said, I don't understand the FPGA market well enough to know if open tooling would be an advantage competitively. With respect to opening documentation: I really do wonder. I don't know the market well enough. For a "we need an FPGA because we need XYZ to be fast and don't have the volume/$ to tape out," of course a good PnR and meeting timing is the #1 concern, and a savvy buyer would choose the best performing solution even if the software suite is brutal to use. But for "we need a PLD for some glue logic, it doesn't need to be 100% blazing fast, it needs to meet XYZ requirements," would a buyer choose a toolchain that worked better and let their engineers go to market faster, even if the PnR wasn't quite as efficient? In that case, opening up documentation and letting the open-source ecosystem build out support could be valuable. What would be telling here would be whether Lattice have seen a measurable sales impact from the reverse engineered open toolchain appearing for their parts. I cynically think that perhaps the idea is futile in this industry, but that's also what everyone thought about graphics and AMD went and did it anyway...

AlphaSite 6y ago

Considering AMDs software chops, I guess that won’t be coming from them.

xbmcuser 6y ago
I thought that was one of the reasons that they acquired Xilinx to improve the software side.
- DoingIsLearning 6y ago
  That was my hope as well, I still dream of Xilinx or Intel deciding to 'LLVM' their toolchain down to bitstream, I keep looking with a lot of interest at Lattice and the Yosys project as it is maturing. These companies make money selling hardware, just open the tools and let people use what they want instead of forcing this 'visual programming' paradigm with half-baked IDEs on everyone. My worry with AMD is what will happen to the SoC chips that have actual ARM cores in the fabric (like the Zynq family)?
  - aseipp 6y ago
    Visual block diagram editors like the one in Vivado, Libero, etc are extremely useful and powerful in practice and an equivalent alternative for open source EDA design would be very welcome. And I'm a person who absolutely loathes Verilog, so it's not like I'm a purist or anything. If that's your representative example of your issues with proprietary FPGA software, I honestly don't think it's a very good one.
    - DoingIsLearning 6y ago
      > 'visual programming' paradigm with half-baked IDEs The paradigm is the least important, when it works, I don't know anyone in real world projects that didn't have to configure something manually through a tcl script because it was either not exposed in GUI or not working in GUI. My issue is not with 'visual programming' my issue is with the 'half-baked' part of the tools. There are too many multi year old bugs that go acknowledged by Xilinx. The VHDL2008 standard came out more than a decade ago and from memory it was only in 2019 that they supported it as a valid simulation file in Vivado. There a plethora of autogenerate/copied/cached files that add a ridiculous amount of friction to any attempt of sane version control. There is just too much complexity in what I assume is an attempt to hide the shoe-horned messiness of the tcl backend and 'prettifying' the GUI frontend.

deleted 6y ago

[deleted]

snvzz 6y ago

There's open source tooling for a bunch of FPGAs: QuickLogic EOS S3 (provided by QuickLogic) Lattice iCE40 (reversed, project icestorm) Lattice ECP5 (reversed, project trellis) Lattice Nexus (reversed, project oxide) Gowin GW1N (reversed, project apicula) Xilinx family 7 (reversed, project x-ray) With more on the works. Hopefully an AMD Xilinx will start contributing to the open source tooling themselves, as they do with CPU and GPU tooling.

rkangel 6y ago

I agree on the 'user friendliness' of FPGA tooling, but SW Engineers (myself including) often make the mistake of thinking an FPGA toolchain is like a software toolchain and therefore everything is equivalent. These are the two main reasons that FPGA toolchains aren't as open as compilers (I'm not saying they're good ones): * Processors have a defined interface ("instruction set") that you can implement a compiler for and have it keep working. The interaction between the FPGA tooling and the FPGA targeted it much more complicated. It's a bit like graphics card drivers and the hardware, where the line between the two is blurry and you have to consider them both together as the graphics system. This means that the 'cleverness' of the design is much more exposed to the toolchain and having that open source would give a way a lot to competitors * Synthesising FPGAs is a LOT harder and more complicated than compiling code (and compiling code is pretty hard). There are many stages in the pipeline involving synthesising the logic and laying it out on the target for best performance. To give an example, we upgraded our toolchain for a Xilinx FPGA and power consumption improved by 20% because they'd changed the ways that they segment clock domains and gate off stuff being used. Good performance in the tooling is a major differentiating factor that you might not want to give away.

regularfry 6y ago
That point about toolchain complexity just reminds me of where compilers were 20 years ago. You could get significant speed bumps because one vendor had an optimisation another didn't. That's probably still true for things like the intel compiler, for all I know. I do remember at one point doing computer vision stuff before NVidia ate the world that it wasn't uncommon to come across code that expected to have access to intel-compiled maths libraries to be able to run in real-time. The point is that the free toolchains got good enough that in general you don't need to care, and I think it's reasonable to expect the same dynamics to apply here.
- pm215 6y ago
  It's still true for compilers -- for instance gcc 10 had a greater than 10% perf improvement for AArch64 targets compared to gcc 9 as a result of various optimisation work: https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/gcc-10-better-and-faster https://community.arm.com/developer/tools-software/tools/b/t...

jhallenworld 6y ago

I'm a bit skeptical on this one. Open tools may help, but for full vendor support you are going to have to use their tools. Also I wouldn't say that their tools are in the dark ages- most of the problems with their tools stem from modern software tool design. So for example, I find Vivado / SDK to be complex yes, but also much more pleasant to use than tool chains for simple micro-controllers. An example is the total mess that is software libraries delivered via STM32CubeMX (no part migration, libraries depend on custom BSPs vs. auto-generated code, good luck preserving your fixes if their auto-generated code has bugs). A reason that the Xilinx tools are big and complex is that they are following modern software tool practices (that I hate): it's a large Java-based tool that aims to hide the underlying relatively simple command line programs. Xilinx tools from the mid-90s are actually closer to what the open source FPGA tools look like today.

stelonix 6y ago

I somewhat agree, but I think the number 1 factor of low FPGA adoption is the absurd price. Put a good price tag like in GPUs and you have a new industry. Of course, there are issues with tooling too. Maybe there needs to be a simplified API, akin to OpenGL, that takes care of the boilerplate.

vmchale 6y ago

clash? I like their mailing list :) https://clash-lang.org/ https://clash-lang.org/

moistbar 6y ago

> FPGA tooling is in the dark ages compared to modern software development environments. Dear god is it ever. My fiancee, bless her, got me a Spartan 6 for Christmas one year. I never got around to using it because I couldn't find a download for the single, outdated version of (I think) Arduino Software it claimed it 100% required.

xyzzy21 6y ago

Absolutely! And the FPGAs need not even be as efficient in packing as Xilinx or Altera. The thing that always gets me: you are already charging for HW - that's the only real business model. The CAD tools 1) suck, 2) aren't going to be a major money maker, and 3) desparately need UI design and programming talent well beyond what ever gets applied today.