4 ms·

> I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. unsufficient tooling? I di

> I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. unsufficient tooling? I did some programming with FPGAs once and it seemed the best option I had for programming was proprietary software by altera (quartus). I never got debugging to work or perhaps I did and I didnt understand the stuff it was showing me (I am no hardware guy) My impression was that an eclipse-like ide, perhaps with a built in HW simulator would make things A LOT easier, especially for beginners like me. Of course this could be completely unrealistic and impractical for hardware design in which case I will show myself out.

_yosefk 13y ago
A free simulator (like iverilog) plus a free waveform viewer (like gtkwave) is a nice way to start fiddling with these things. Verilog is way - WAY - easier to deal with than say C, actually, because you have much more visibility (waves instead of a variable view) and much better error detection (none of those bloody memory overruns, built-in Valgrind with the "X" values, etc.) I'm a programmer by training, and I got into hardware architecture in part because of how fun Verilog was, actually - seeing all this stuff. Compile and run Verilog online (which is how I tested the Verilog code in the article): http://www.compileonline.com/compile_verilog_online.php http://www.compileonline.com/compile_verilog_online.php Running on FPGA without testing on a simulator first can indeed be tough for a newcomer, I'd guess.
- simias 13y ago
  I've started to learn hardware design a couple of months ago and this is good advice. However I'd like to mention that many constructs work fine in simulation but are completely backwards/impossible to synthesize in FPGA or ASIC. Writing verilog is easy, writing good verilog much more difficult. I don't know if there are any good and comprehensive resources for learning hardware design coming from a software background, I have the chance to work with some ASIC guys who can help me with those things.
  - deleted 13y ago
    [deleted]
- jlgreco 13y ago
  Eh, gtkwave is the sort of thing that I feel allergic to. I've used it extensively in the past but at no point was it something that I enjoyed having to use. Moreso than not liking to work with proprietary software, what I really don't like to do is work with non-browser/non-terminal based programs. Those sort of tools just really don't seem like tools that were designed with users like me in mind. If I have to work with programs like that then I of course will, but in my personal time that sort of program drives me away. If gtkwave took some high-level inspiration from graphviz, that would be great. Also, good god is GHDL horrific...
alok-g 13y ago
I seriously want someone to disrupt FPGA tooling. In my understanding the tooling for FPGAs has been made purposefully complicated to achieve a lock-in. The issue is that adoption of new tooling practically requires compatibility with the existing tools from the two key market holders, and I do not think even they themselves could do that anymore.
- _yosefk 13y ago
  It's genuinely complicated; if Xilinx could disrupt Altera by making easier-to-use tools, it would. (In fact it tries with AutoESL.) I hope to explain why FPGA tooling is intrinsically hard in my next write-up.
  - amirhirsch 13y ago
    here's a few good reasons why it's hard to make easy-to-use vendor-neutral FPGA tools: - all the devices/bitstream formats are proprietary with little or no documentation of the logic blocks or programmable interconnect structures. it is probably technically easier to build a new FPGA from scratch and design tools for that, than to reverse engineer existing chips [1] - there is very little cross-compatibility between vendor products (a 4-lut here, a 6-lut there, some carry-chain logic here, a DSP block there) - all the optimizations (synthesis, place-and-route) are NP-hard problems - sequential imperative (C-like) thinking is not the correct way to make parallel systems - the FPGA vendors compete on tools and offer their software for free to push hardware. hard for an independent vendor to compete. [1] some reverse engineering efforts exist. see "From the bitstream to the netlist" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.6043&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117... / http://code.google.com/p/debit/ http://code.google.com/p/debit/
    - alok-g 13y ago
      While I find your comment informative, points 3 and 4 do not really explain why vendor-neutral tools cannot exist. Point 2 (my best understanding) should not be a breaking issue if documentation and specifications are available (which is covered by point 1). It seems to me that point 5 is part of the thing they have done to prevent alternative tools to come to market. Lastly, point 1 is exactly what begs for disruption.

_yosefk 13y ago

A free simulator (like iverilog) plus a free waveform viewer (like gtkwave) is a nice way to start fiddling with these things. Verilog is way - WAY - easier to deal with than say C, actually, because you have much more visibility (waves instead of a variable view) and much better error detection (none of those bloody memory overruns, built-in Valgrind with the "X" values, etc.) I'm a programmer by training, and I got into hardware architecture in part because of how fun Verilog was, actually - seeing all this stuff. Compile and run Verilog online (which is how I tested the Verilog code in the article): http://www.compileonline.com/compile_verilog_online.php http://www.compileonline.com/compile_verilog_online.php Running on FPGA without testing on a simulator first can indeed be tough for a newcomer, I'd guess.

simias 13y ago
I've started to learn hardware design a couple of months ago and this is good advice. However I'd like to mention that many constructs work fine in simulation but are completely backwards/impossible to synthesize in FPGA or ASIC. Writing verilog is easy, writing good verilog much more difficult. I don't know if there are any good and comprehensive resources for learning hardware design coming from a software background, I have the chance to work with some ASIC guys who can help me with those things.
- deleted 13y ago
  [deleted]
jlgreco 13y ago
Eh, gtkwave is the sort of thing that I feel allergic to. I've used it extensively in the past but at no point was it something that I enjoyed having to use. Moreso than not liking to work with proprietary software, what I really don't like to do is work with non-browser/non-terminal based programs. Those sort of tools just really don't seem like tools that were designed with users like me in mind. If I have to work with programs like that then I of course will, but in my personal time that sort of program drives me away. If gtkwave took some high-level inspiration from graphviz, that would be great. Also, good god is GHDL horrific...

alok-g 13y ago

I seriously want someone to disrupt FPGA tooling. In my understanding the tooling for FPGAs has been made purposefully complicated to achieve a lock-in. The issue is that adoption of new tooling practically requires compatibility with the existing tools from the two key market holders, and I do not think even they themselves could do that anymore.

_yosefk 13y ago
It's genuinely complicated; if Xilinx could disrupt Altera by making easier-to-use tools, it would. (In fact it tries with AutoESL.) I hope to explain why FPGA tooling is intrinsically hard in my next write-up.
- amirhirsch 13y ago
  here's a few good reasons why it's hard to make easy-to-use vendor-neutral FPGA tools: - all the devices/bitstream formats are proprietary with little or no documentation of the logic blocks or programmable interconnect structures. it is probably technically easier to build a new FPGA from scratch and design tools for that, than to reverse engineer existing chips [1] - there is very little cross-compatibility between vendor products (a 4-lut here, a 6-lut there, some carry-chain logic here, a DSP block there) - all the optimizations (synthesis, place-and-route) are NP-hard problems - sequential imperative (C-like) thinking is not the correct way to make parallel systems - the FPGA vendors compete on tools and offer their software for free to push hardware. hard for an independent vendor to compete. [1] some reverse engineering efforts exist. see "From the bitstream to the netlist" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.6043&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117... / http://code.google.com/p/debit/ http://code.google.com/p/debit/
  - alok-g 13y ago
    While I find your comment informative, points 3 and 4 do not really explain why vendor-neutral tools cannot exist. Point 2 (my best understanding) should not be a breaking issue if documentation and specifications are available (which is covered by point 1). It seems to me that point 5 is part of the thing they have done to prevent alternative tools to come to market. Lastly, point 1 is exactly what begs for disruption.