If you hadn’t noticed, we had a bit of an FPGA theme running at this year’s Superconference. Why? Because the open-source FPGA toolchain is ripening, and because many of the problems that hackers (and academics) are tackling these days have become complex enough to warrant using them. A case in point: David Williams is a university professor who just wanted to build a quadruped robotics project. Each leg has a complex set of motors, motor drivers, sensors, and other feedback mechanisms. Centralizing all of this data put real strains on the robot’s network, and with so many devices the microcontrollers were running out of GPIOs. This lead him to become, in his words, “FPGA-curious”.
If you’re looking for a gentle introduction to the state of the art in open-source FPGAs, this is your talk. David covers everything, from a bird’s eye view of hardware description languages, through the entire Yosys-based open-source toolchain, and even through to embedding soft-CPUs into the FPGA fabric. And that’s just the first 18 minutes. (Slides for your enjoyment, and you can watch the talk embedded below the break.)
The second half of the talk is more about his personal experience and advice based on the last year or so of his experience going from FPGA newbie to master of his own robot. He highlights the versatility of a soft-CPU in an FPGA versus a pre-baked microcontroller solution. With the microcontroller you get all of the peripherals built into the silicon, but with the FPGA you get to write your own peripherals. Want a 10-wire SPI-like bus? Just code it up. Your peripherals are as simple or complex as you need them to be.
On the hardware side, David touts the PMOD standard (a man after our own heart!) and points out the large ecology of PMOD-compatible devices out there. Going for a plug-in solution also means that your engineering job is reduced to building a carrier board that can seat the FPGA brainboard of your choosing and interface it with a bunch of PMODs. It’s hard to get much simpler than that.
David is very much interested in the software layer as well, and encouraging re-usability of Verilog code among designs. Towards this end he’s written his own bus and interconnect standard, and a few modules that do things such as buffer data, process video, and so on. While we would have probably gone for the open-source standard WISHBONE interconnect architecture, David bundled a bunch of the possible signals together and called it a “pipe”. Compared to WISHBONE, David’s design makes a few judicious choices and thus streamlines interconnection greatly. He has code to go with it all, so have a look if you’re interested. We’re just speculating, but if you wrote a “pipe” to WISHBONE connector, you’d have the best of both worlds.
Finally, David isn’t just whistling Dixie. He took a video camera, plugged it into his Supercon badge via the cartridge slot, and had it displaying video in real time, all of this using pieces of code that he’d previously written and simply connected together with his “pipes”. A great demo is very convincing.
In sum, David’s talk is a great summary of the state of play in open-source FPGAs right now. Whether you’re getting your first taste, or are a moderately skilled FPGA developer, there is something for you here. And if anything, David’s call to end the fifty years of secrecy and IP-hoarding that have surrounded FPGAs is a rallying cry that we can get behind. We’ve gotten the tools in our hands now, and the hardware has become cheap and accessible. If you’re looking for a place to start, try the self-guided FPGA workshop from Supercon, and then maybe Al Williams’ FPGA Bootcamp. The time for a hacker FPGA revolution is ripe. To arms!
“And if anything, David’s call to end the fifty years of secrecy and IP-hoarding that have surrounded FPGAs is a rallying cry that we can get behind. ”
And greater speeds is always appreciated.
“Towards this end he’s written his own bus and interconnect standard, and a few modules that do things such as buffer data, process video, and so on. While we would have probably gone for the open-source standard WISHBONE interconnect architecture”
I think AXI4/AXI4-Stream’s kinda won that battle. It’s sometimes useful to create your own interconnect for whatever reason, but for any real design I’d say just use AXI4 busses everywhere. You’ll save yourself a ton of time.
Hoe so? Wishbone is open spec and open source, axi is only royalty free. I’m not sure if open source implementations exist…
That said, yes with the drag/drop ability of vivado et all, using axi is trivial. But that’s usually the bane of open source right?
The Pipeline idea isn’t a bus, really. It’s just a wrapped-up Data+Ready+Valid bundle with a few other signals optionally added. So no addressing, merely a way to generically connect data sources and sinks. It should be noted that this is IDEAL for FPGA’s since it allows everything to happen at once and to be self synchronizing. For example I’m working on an image scaler so the camera to LCD pipeline might look like this:
Camera->FIFO->Scaler->Gray2RGB->LCD
Here, the LCD is the slowest thing, so it’s pace dictates how things run through the pipeline. The camera is given long Horizontal blanking times and a FIFO to make sure it’s never held up.
One other thing about pipelines is that they can operate at one operation per cycle – when ready and valid are high, data flies through. This is a thing of beautify, but it does make stalls harder. I’m still trying to write the perfect pipeline component.
They should have used HDMI2USB and captured the slides separately. (It’s an FPGA-driven open source design, too!)
So, Elliot,
he’s your brother, along with Al?
B^)
And our tennis-playing sisters!
Thanks for the write-up, Bro. Very nice. Not a university professor, though!
Usually its best to deal with this in post production. Camera always on guy, secondary stream on the slides. Then in post, switch between pip of slides/presenter
Great talk! Very good speaker.
David rightly calls out the deplorable state of shared components in the HDL world, but I’m surprised he has nothing to say about the deplorable state of Verilog itself. The more I use it, the more I realize how unfit it is for complex designs.
You’re not alone in thinking this, and there are a few higher-level languages that can compile down to Verilog for you.
I don’t know if any of them have “won” yet, that’s something I’m interested in checking out. Migen is first on my list.
SpinalHDL is probably next.
Hi, Eliot. Yes I’m aware. I’ve been using nMigen for the last couple of months, though I’m still an FPGA noob.
nMigen is winning me over — being embedded in Python makes it possible (though not easy) to write programs to write HDL. The built-in simulator makes it almost easy to attach a test bench to every module and create unit tests. And powerful Python libraries like numpy and tensorflow are just an import statement away — they’re useful for BRAM initialization if nothing else. Since Python isn’t designed to be extended, the low level syntax of nMigen is clunky, though.
I intend to immerse myself in Chisel and Spatial at some point, too.
Good point. Being a noobie as I was, I really had nothing to compare Verilog to. Certainly I was aware of Migen and SpinalHDL, but I thought that starting from the basics was a good idea. One year later and 10’s of thousands of lines later, I am much better at Verilog than I was, very aware of the language flaws, and open to try some other things.
There are other Verilog escape hatches – one being the use of a SoftCPU. Then you have less work in Verilog and the remainder in C or whatever. This is a pretty amazing option. The other escape hatch is a guilty pleasure I worked on over my recent vacation. It’s the idea of using Verilog macros, tasks and functions to make a domain specific language in Verilog which might permit yet another way to make things easier. More of that anon. I’m going to keep working on that until someone wiser and more experienced tells me to stop hurting myself.
Thanks for the great talk.
As I understand it, Chisel supersedes SpinalHDL. nMigen is intended to supersede Migen, though it’s only v0.1 and not prime time ready yet.