FPGA Design for Software Engineers
The problem of FPGAs is their proprietary nature, and Verilog/VHDL are far from the best languages. Gladly there is a number of open-source projects aiming to close this gap - Yosys[1], SymbiFlow[2], Chisel3[3]/FIRRTL[4]. Some time ago I suggested[5] different open source projects should unite and reuse the common intermediate language, akin to LLVM in many software development and analysis tools. From my point of view, FIRRTL is the best designed one, there is a huge problem of being implemented in Scala though, especially for C/C++/etc written projects. Hopefully, there will be more collaboration one day. Either reimplementation from scratch, e.g. in Rust or C++, or using Scala Native.
[1] https://github.com/YosysHQ
[2] https://symbiflow.github.io/
[3] https://www.chisel-lang.org/
I am curious, why System Verilog isn’t mentioned in this article. It is much much better than Verilog and is used in industrial applications.
What I am missing are 2 topics: timing analysis and debugging. Static timing analysis and proper timing constrains are crucial for functional design. No tool can differentiate without constrains a slow signal signal toggling LED every 10 seconds from DDR3 533 MHz differential clock line.
Debugging FPGAS design cannot be avoided. Even if design works in simulator, it fails very often on real hardware. And then real fun starts. Xilinx has Integrates Logic Analyzer, Intel has Chipscope. Other vendors have their own similar tools. There are best FPGA designer’s friends. But these tools can’t be trusted, they break sometimes design in unexpected ways. Designer must develop gut feeling, what’s happening. Synthesis of design with integrated logic analyzer takes much more time than regular one. Debugging cycles are insane long. Forgetting one signal can mean 2 hours waiting, so add them all at very beginning.
Writing hardware description language is easy part. As somebody already mentioned, everybody can count ones and zeros. First problem every software engineer encounters is simple: there is nothing to program. FPGA design is about describing your system with these ancient language. Second problem is using bulky toolchain. It’s more than compile and debug buttons. In fact, there is huge machine processing code to bitstream. And it’s complexity naturally takes time to understand, you don’t need to be smart to be FPGA designer.
This is a pretty nice tutorial! My courses in FPGA design in school taught me a ton about 1) concurrency and 2) good state machine design. In modern backend web development these topics receive so little attention (from interviewing all the way to writing technical specs, I've rarely encountered these topics brought up explicitly) but are important. I was a bit hesitant for this guide to suggest using C++ since I tend to dislike mixing traditional languages with hardware languages but I realized it was just for testbenches, which is very reasonable (and even VHDL exposes things like `for` loops that are really only useful for testing and meaningless otherwise - sans some special cases[1]).
[1] You can abuse some imperative paradigms to implement things like Conway's Game of Life as a systolic array - https://en.wikipedia.org/wiki/Systolic_array
I wrote tetris in verilog that can output to VGA 10 years ago for a university project. The code is here: https://github.com/jeremycw/tetris-verilog for anyone interested. Comments are sparse but it might be interesting for anyone looking for some example code that's relatable.
I recently got a TinyFPGA-BX, and have been slowly working through the tutorials. The amusing thing is that, for the actual applications I'm working on, a contemporary microcontroller can actually keep up just fine, and is easier for me to comprehend. Still, one of these days, a use will for an FPGA will crop up for which I'll be glad that I learned.
For people who are curious about FPGAs looking to dip their toes in, I’d highly recommend taking a look at cocotb https://github.com/cocotb/cocotb
It’s kind of similar to verilator, in that it lets you write test benches for your designs in programming languages as opposed to HDL. Whereas verilator lets you write c++, cocotb is python based.
Both of these are probably best to take up after spending some time with an hdl, so you learn to think from a hardware perspective.
Also check out the zipcpu blog
That's a good intro. What I always have to remind software guys who switch to FPGA design is remember each line you write is eventually going to end up in hardware.
That means when you write something you should have some understanding of the underlying hardware inferred. So is this going to give me some combinatorial logic, a register or a RAM? It's very easy to keep the software mindset of if it compiles then it's good.
Great article, I wish the discussions around clocks had gone a bit more into how the tradeoff of pipelining vs longest operation ends up impacting designs. That and SRAM vs DRAM access latencies were the things that really connected the dots from how performance optimization on the software side of things is rooted in physical hardware limitations.
I've been looking for something like this for a while. It's hard to break into FPGA design coming from a Software Engineering viewpoint, but I think it teaches how the machine REALLY works and can produce better Software developers.
If any of you are interested in FPGA's after reading the article I highly recommend:
Introduction to Logic Circuits & Logic Design with VHDL by Brock J LaMeres
He was my instructor in college and the text itself is extremely helpful for all things FPGA.
Thank you, that was interesting. I've programmed microcontrollers, but I've never tangled with ASICs or FPGAs. Too scared, I guess.
Your article has reduced my fear (and also, you mentioned the price of that Tiny FPGA board; at that price point, I don't mind too much if the magic smoke gets out).
FPGAs are getting larger, more complex, and significantly harder to verify and debug https://semiengineering.com/fpga-design-tradeoffs-getting-mo...
I'm surprised that no one has brought up the Lattice IceStick. It's an oversized USB stick with an ice40 FPGA on it and it's the cheapest option I've seen.
Wow this is a gift from God. I was doing fpga for my CV and this just made my life a lot easier
Cool! Back in college we used fpgas with verilog! The labs always took some finagling to get working, but still very fun!
little nitpick:
it's "combinational circuits", not "combinatorial" (that's whole another part of math)
Small error in the article: 200*10e6 is 2GHz, not 200MHz.
Good reference!
True
Keep the Python loving freaks away from my FPGAs
Ten years ago, in grad school, I co-wrote a video conferencing module in VHDL [0]. I haven't touched HDLs since but here's what I remember very clearly from that project:
* It took > 3 minutes to compile our code.
* DMA made a huge performance difference once we figured it out.
* Realizing that we had to be one with the clock tick took a lot of time. Understanding synchronous based programming (if that's the term) was a paradigm shift for my partner and I.
* The utter delight when we got frames streaming across the wire. The performance (though over a LAN) was silky smooth and you could tell immediately this was different than the run-of-the-mill x86 desktop program.
[0] - http://www1.cs.columbia.edu/~sedwards/classes/2009/4840/repo...