7 ms·

I learned VHDL a few months ago. Since then I've build a few projects with it (some PCIe and ethernet stuff). I was very excited to learn a HDL because FPGAs se

I learned VHDL a few months ago. Since then I've build a few projects with it (some PCIe and ethernet stuff). I was very excited to learn a HDL because FPGAs seem like extremely powerful devices. However, I now know why FPGAs aren't as popular as they could be: the tools are horrible. There is no way FPGAs will become popular among software developers unless the tooling improves dramatically. You can really tell that it was all build by hardware engineers who know their electronics very well, but not good software design.

anfractuosity 10y ago
Cool! I'm going to attempt to learn VHDL, as I just picked up a Zybo board to learn with. I'm just wondering what you used for PCIe out of interest? A while ago I picked up an Igloo2 board, but found their software impossible to use under Linux alas.
- AlexanderDhoore 10y ago
  I've been working with a NetFPGA 10G board. It's quite cheap for academic research, but not for hobbyists. It's also rather old now. The project comes with open source HDL, but I've had immense trouble getting it to work. You need a special license from Xilinx just to get started (ethernet core). I wish I had chosen something else. I tried a Lattice ECP5 Versa board, but you need to sign a NDA just to get the ethernet documentation, which of course is impossible.
metaphor 10y ago
> There is no way FPGAs will become popular among software developers unless the tooling improves dramatically. Care to expound in what way? I don't disagree with your opinion completely, but I suspect our reasons differ. IMHO, the barrier isn't so much the tools, but a clashing of paradigms. All too often, traditional software developers without a solid foundational background in digital hardware architectures think they can easily pick up a HDL as if it were yet another programming language. The HD part is quickly forgotten as behavioral processes are hacked away using all too familiar constructs like if-then-else, for/while loops, etc. Inference warnings are ignored, timing constraints are shrugged off, metastability and synchronization aren't even a thing, let alone driver/receiver selection, pinmap planning, and signal integrity considerations at the PCB level...set to default and things should just work, right? Anecdotally speaking, the only thing in common that HDLs have with traditional programming languages is a superficial charset. I think every software developer who has ever used tools like VS, Eclipse, Emacs, Vim, Make, Doxygen, Git, etc. would agree that each has its quirks and it takes a bit of use before a comfortable flow is discovered. FPGA vendor tools are no different, except--testbed simulations aside--there's that immutably distinct custom hardware integration end-game that most traditional software has the pleasure of conveniently abstracting away. Any kernel/driver developers with HDL proficiency care to chime in? P.S. ground-up PCIe/Ethernet FSM+datapath architectures after a few months without prior HDL experience is really impressive.
- ploxiln 10y ago
  I went to CMU for a BS in EE, I used a lot of verilog, and also a bit of Cadence for layout in one class. But I've worked as a software engineer since then. I totally agree that HDL tools are astonishingly crap. The market is just so much more specialized, expensive, locked down and closed. Imagine that you had to use the Intel compiler to get source code compiled for intel processors. You had to use their special headers, you practically had to use their huge 8GB Intel IDE with a million lists and buttons, you had to choose what features were on your intel processor (VT-X? SSE4?). Imagine AMD is the same, but separate. This is all closed source stuff of course. And you have to use it to run on any smartphone/laptop/desktop/server class processor. Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. All the related tools we use wouldn't have much of a reason to exist because just about everyone had to use the huge IDEs for each vendor anyway. The vendor stuff is huge and inefficient and crap, because features sell, and crap doesn't not sell because there's no meaningful competition. To be more specific, "crap" means high bloat and low reliability. Crashes, inexplicable errors and failures. Huge amounts of bloat. But you can make a tweak and try again move on, so any sane hardware person just gets used to it, it's not like they can do anything about it.
  - metaphor 10y ago
    Apologies but I really can't tell if your point is against the proprietary nature of reconfigurable devices, or vendor tool bloat. > Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. This is quite easy to imagine when you remove the key element which allows these L7 abstractions to be meaningful: an underlying kernel with a well defined interface. What equivalence does the reconfigurable world have when every target device requires its own unique "kernel", if you will? I can't think of any...which would explain why 3rd-party tools are constrained to synthesis, while place-and-route is an explicit function of the vendor tool. Perhaps we too easily conflate the size of the tool with the size of the target? On the flip side, supposing there were some open reconfigurable interface standard, I don't think this would fly in the current market given the high-performance nature of these devices. Top two FPGA vendors apparently change slice/CLB structure every generation, let alone agree on an open fabric interface standard. > Crashes, inexplicable errors and failures. Huge amounts of bloat. Putting the whole kit and kaboodle aside and focusing on just synthesis, isn't it strange that even the big, specialized 3rd party vendor tools (e.g. Cadenace, MG, Synopsis) suffer just as much? I think it's a genuinely difficult problem given the multi-disciplinary nature of the things EDA engineers have to deal with. As much as I dislike dealing with flake tools, I'm nevertheless humbled by their challenges.
lnsru 10y ago
There are many projects started some 10 years ago with Cyclone III FPGA and vendors do not want to scare the folks working with the same Quartus since then. I wish I could simply synthesize my algorithms from C code instead writing that VHDL or Verilog code. SystemVerilog is a bit better, but the company does not allow using it.
- metaphor 10y ago
  Cyclone III was last supported in v13.1[1] of Quartus, which had a Nov-2013 release date[2]. Curiously, Figure 2 in this white paper[3] depicts all Cyclone models active as of March 2014, suggesting their tool went through significant refactoring with some big picture in mind, considering support for a largely active family wasn't continued. Not sure how much scaring folks away factored into their decision. [1] http://dl.altera.com/devices/ http://dl.altera.com/devices/ [2] http://dl.altera.com/13.1/?edition=web http://dl.altera.com/13.1/?edition=web [3] https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/wp/wp-01216-fpga-eol-indicators.pdf https://www.altera.com/content/dam/altera-www/global/en_US/p...
sguav 10y ago
I feel the need to echo metaphor's reply. Even if tools for FPGAs do become better through the years, it doesn't mean they'll become "sw dev friendly". If you do software you should be fluent with data structures, while on the FPGA/hardware side you "speak" metastability control and timing constraints. Just separate fields of interest. When high level synthesis tools arise (such as Xilinx HLx, C -> straight to FPGA implementation) I still feel they are aiming the wrong audience: these tools still require a more-than-average knowledge of the FPGA fabric and implementation to work with, and that may be a good thing, but defies the HLS paradigm at its roots IMHO. Source: humble experience through my job as an FPGA designer

anfractuosity 10y ago

Cool! I'm going to attempt to learn VHDL, as I just picked up a Zybo board to learn with. I'm just wondering what you used for PCIe out of interest? A while ago I picked up an Igloo2 board, but found their software impossible to use under Linux alas.

AlexanderDhoore 10y ago
I've been working with a NetFPGA 10G board. It's quite cheap for academic research, but not for hobbyists. It's also rather old now. The project comes with open source HDL, but I've had immense trouble getting it to work. You need a special license from Xilinx just to get started (ethernet core). I wish I had chosen something else. I tried a Lattice ECP5 Versa board, but you need to sign a NDA just to get the ethernet documentation, which of course is impossible.

metaphor 10y ago

> There is no way FPGAs will become popular among software developers unless the tooling improves dramatically. Care to expound in what way? I don't disagree with your opinion completely, but I suspect our reasons differ. IMHO, the barrier isn't so much the tools, but a clashing of paradigms. All too often, traditional software developers without a solid foundational background in digital hardware architectures think they can easily pick up a HDL as if it were yet another programming language. The HD part is quickly forgotten as behavioral processes are hacked away using all too familiar constructs like if-then-else, for/while loops, etc. Inference warnings are ignored, timing constraints are shrugged off, metastability and synchronization aren't even a thing, let alone driver/receiver selection, pinmap planning, and signal integrity considerations at the PCB level...set to default and things should just work, right? Anecdotally speaking, the only thing in common that HDLs have with traditional programming languages is a superficial charset. I think every software developer who has ever used tools like VS, Eclipse, Emacs, Vim, Make, Doxygen, Git, etc. would agree that each has its quirks and it takes a bit of use before a comfortable flow is discovered. FPGA vendor tools are no different, except--testbed simulations aside--there's that immutably distinct custom hardware integration end-game that most traditional software has the pleasure of conveniently abstracting away. Any kernel/driver developers with HDL proficiency care to chime in? P.S. ground-up PCIe/Ethernet FSM+datapath architectures after a few months without prior HDL experience is really impressive.

ploxiln 10y ago
I went to CMU for a BS in EE, I used a lot of verilog, and also a bit of Cadence for layout in one class. But I've worked as a software engineer since then. I totally agree that HDL tools are astonishingly crap. The market is just so much more specialized, expensive, locked down and closed. Imagine that you had to use the Intel compiler to get source code compiled for intel processors. You had to use their special headers, you practically had to use their huge 8GB Intel IDE with a million lists and buttons, you had to choose what features were on your intel processor (VT-X? SSE4?). Imagine AMD is the same, but separate. This is all closed source stuff of course. And you have to use it to run on any smartphone/laptop/desktop/server class processor. Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. All the related tools we use wouldn't have much of a reason to exist because just about everyone had to use the huge IDEs for each vendor anyway. The vendor stuff is huge and inefficient and crap, because features sell, and crap doesn't not sell because there's no meaningful competition. To be more specific, "crap" means high bloat and low reliability. Crashes, inexplicable errors and failures. Huge amounts of bloat. But you can make a tweak and try again move on, so any sane hardware person just gets used to it, it's not like they can do anything about it.
- metaphor 10y ago
  Apologies but I really can't tell if your point is against the proprietary nature of reconfigurable devices, or vendor tool bloat. > Imagine that there's no GCC, no CLANG, no GDB, no Jetbrains, no Eclipse. This is quite easy to imagine when you remove the key element which allows these L7 abstractions to be meaningful: an underlying kernel with a well defined interface. What equivalence does the reconfigurable world have when every target device requires its own unique "kernel", if you will? I can't think of any...which would explain why 3rd-party tools are constrained to synthesis, while place-and-route is an explicit function of the vendor tool. Perhaps we too easily conflate the size of the tool with the size of the target? On the flip side, supposing there were some open reconfigurable interface standard, I don't think this would fly in the current market given the high-performance nature of these devices. Top two FPGA vendors apparently change slice/CLB structure every generation, let alone agree on an open fabric interface standard. > Crashes, inexplicable errors and failures. Huge amounts of bloat. Putting the whole kit and kaboodle aside and focusing on just synthesis, isn't it strange that even the big, specialized 3rd party vendor tools (e.g. Cadenace, MG, Synopsis) suffer just as much? I think it's a genuinely difficult problem given the multi-disciplinary nature of the things EDA engineers have to deal with. As much as I dislike dealing with flake tools, I'm nevertheless humbled by their challenges.

lnsru 10y ago

There are many projects started some 10 years ago with Cyclone III FPGA and vendors do not want to scare the folks working with the same Quartus since then. I wish I could simply synthesize my algorithms from C code instead writing that VHDL or Verilog code. SystemVerilog is a bit better, but the company does not allow using it.

metaphor 10y ago
Cyclone III was last supported in v13.1[1] of Quartus, which had a Nov-2013 release date[2]. Curiously, Figure 2 in this white paper[3] depicts all Cyclone models active as of March 2014, suggesting their tool went through significant refactoring with some big picture in mind, considering support for a largely active family wasn't continued. Not sure how much scaring folks away factored into their decision. [1] http://dl.altera.com/devices/ http://dl.altera.com/devices/ [2] http://dl.altera.com/13.1/?edition=web http://dl.altera.com/13.1/?edition=web [3] https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/wp/wp-01216-fpga-eol-indicators.pdf https://www.altera.com/content/dam/altera-www/global/en_US/p...

sguav 10y ago

I feel the need to echo metaphor's reply. Even if tools for FPGAs do become better through the years, it doesn't mean they'll become "sw dev friendly". If you do software you should be fluent with data structures, while on the FPGA/hardware side you "speak" metastability control and timing constraints. Just separate fields of interest. When high level synthesis tools arise (such as Xilinx HLx, C -> straight to FPGA implementation) I still feel they are aiming the wrong audience: these tools still require a more-than-average knowledge of the FPGA fabric and implementation to work with, and that may be a good thing, but defies the HLS paradigm at its roots IMHO. Source: humble experience through my job as an FPGA designer