Hacker News Reader

Comment by syntaxing | Hacker News Reader

All these new affordable FPGA are getting really tempting to learn more about them. I've been debating for a while to get the TinyFPGA BX board from Sparkfun. Though I don't have a specific application yet. Are FPGA used in robotics often? Or is the response time so low (relatively) that it makes more sense to stick with a uC?

Side note, this might seem like stupid question, but can anyone explain what APIO[1] is (which TinyFPGA uses)? I'm kind of confused what it's used for.

[1] https://github.com/FPGAwars/apio

View on HN

You aren't going to be able to build a super-fast CPU on an FPGA but there are plenty of other tasks you could give it. You can build a processor for analyze multiple sensors, looking for specific events that you could then feed to the uC or setup a DSP pipeline to filter the sensor data to look for patterns. The nice thing about an FPGA is that there is no interruption when it's running. The uC might be trying to feed data over wifi to the controller station and polling sensors/analyzing sensor data is going to bog things down really quick. Another task for an FPGA would be to act as a switch for a network within the robot. It would sit between all of the sensors/actuators and an ethernet-enabled uC located elsewhere in the robot. The FPGA would read command packets from the uC and translate tasks like "read temperature sensor #5" or "turn 15 degrees" into specific impulses on the pins while also turning sensor and feedback data into packets to send back to the uC. You could even run video feeds from cameras back to the uC over gigabit if the FPGA supports it. This way you can run a cheap, small uC to control things from a higher level while the i/o-plentiful FPGA does all the heavy lifting at 100Mb/s speeds.

Something like this sounds super interesting. Is it hard to get the FPGA to talk the uC? I own the DSP book by Proakis/Manolakis, but I picked it up only twice...so my understanding of DSP is pretty abysmal.

There are SPI, I2C, ethernet, and UART blocks that you can usually just drop right into your design for communicating with external chips.

As someone who just started getting into it, it's kinda hard to come up with an application until you have one and know how to use it a bit. I bought an icestick not knowing what I was going to do with it, but now I have quite a few ideas. They can be useful in robotics, as glue logic, for sensor fusion or for very precise real-time applications.

apio is a command line tool that automates installing the toolchain for your FPGA and running it. It just simplifies things, you don't have to use it if you'd rather call the individual tools for synthesis, P&R, simulation etc. It'd be reasonable to think of it as akin to a very smart Makefile combined with an automatic package manager, specialized to FPGAs (it's based on PlatformIO). It's nice when you're still kind of getting oriented, because you don't need to know how to set up and invoke the different tools... just call `apio build` or `apio simulate`.

Did you know Verilog or VHDL beforehand? I'm super interested in doing sensor fusion (or even just basic sensoring like a UKF). But it seems so overwhelming (compared to a uC like Arduino or ESP8266), I don't even know where to start. Do you have any tips or tutorials that you recommend?

Thank you for the explanation for APIO! Do you use it often? Or are there alternatives that people use when they get to a certain level (Like Atom/VScode --> vim)?

I'm loosely in a similar boat. I learned a little Verilog and implemented a MIPS CPU with pipelining, and did some small scale stuff based on papers about systolic arrays for matrix multiplication (a la TPU).

It feels to me like there is an enormous gap between the level of complexity in implementing a simple CPU like I did to something that would actually be useful to anyone, even something relatively small and basic. Things like integrating with other components or building up more complex designs feel outside my reach.

The resources I find are generally targeted either towards a very basic level of how electronics work or a very specific level of a particular task with a device. This seems like a really interesting area, but difficult to get comfortable with.

I totally agree. I followed a couple tutorials on how to make a LED blink but it doesn't really provide much substance. The other popular tutorial is a NTSC/PAL decoder that usually goes way over my head...I'm hoping with all these affordable FPGA, there will be boom like the early 2010s boom of Arduino!

I had some exposure to VHDL, but only from a workshop I attended and it wasn't really any more than you could get from watching YouTube tutorials. I prefer Verilog now anyway as it's way more concise.

The best place to start is to just grab a book and an FPGA kit and go. You'll probably have to try a bunch of tutorials until you find one that clicks for you and after that it gets easier. For iCE40 you can also check out IceStudio, which is a graphical block based IDE that can be helpful for getting your feet wet. Get some hardware to give you feedback and play with, e.g. a 7-segment display and implement a driver yourself. Watch YouTube videos to get an idea of the general flow of things and eventually it'll make sense. IMO it helps a lot if you have a background in electronics, if not you're gonna be in pretty deep.

I use apio because it's convenient. Hardcore FPGA devs are going to use the manufacturer's IDE. The official Lattice tools for the iCE40 are unbelievably awful and there's not much to gain from using their iCECube2 IDE versus open source ones, but in most cases you don't have any choice in the matter and have to use the manufacturers tools. This isn't so bad though, I've had some exposure to Xilinx's ISE and Vivado and they are pretty decent, plus Xilinx gives you access to a ton of free IP cores that you can drop into your design.

IceStudio looks awesome and is exactly what I need! Thank you for the suggestions!

Yeah, the only downside is that it doesn't support simulation yet, which is super important for doing anything non-trivial. I think just a few minutes of playing with it and looking at the examples (it has a bunch of really good ones) is enough to help make a lot of progress. That's how it was for me, anyway. It was the little nudge I needed to start understand what was going on.

Decoding rotary encoders is a common task, and very hard to do with Microcontrollers at either high event rates or multiple instances.

Maybe even turning a brushless motor with an encoder into a servo motor.

My main idea for using FPGAs would be talking to a couple of i2c/spi sensors and reducing the data rates. Some sensors only have one or two possible i2c addresses, some require multiple requests to get a limited amount of data, reducing the polling frequency.

Typical uses for FPGAs in robotics include basic processing on the high bandwidth bitstreams from cameras or laser scanners into a format / representation more easily handled by the main CPU (building a depth map from the raw laser scanner photodiode stream, for example).

They are also used on the motor control side, though these days a motor control mcu may be more practical in most cases today.

A useful example project would be an FFT or OFDM accelerator for a microcontroller. Most microcontrollers really struggle with FFT so it is an example where a small uC and a small FPGA can be cheaper than a large uC. Sliding window FFT is going to be another good example where the FPGA option is competitive.

Reply on news.ycombinator.com