Everywhere people are buzzing about FPGA — Field-Programmable Gate Array. It’s a computing device that works like an Arduino Microcontroller — but in a different way. A microcontroller contains a CPU that executes instructions one at a time (but it can’t run 2 instructions simultaneously). Instead of CPU instructions, an FPGA uses a grid of electronic Logic Modules which contain bundles of Logic Gates like AND, OR, NOT. The grid looks like this (from my imagining):
Grid of logic modules in an FPGA. Colour lines represent connections between logic modules.
How do you program an FPGA? The FPGA allows you to “burn” connections between the logic modules to make up complex processing logic, similar to CPU instructions. In fact you could build a CPU out of an FPGA since they are both based on logic gates.
FPGA Starter Board: https://www.ebay.com.au/itm/XC6SLX9-Starter-Board-Xilinx-Spartan-6-FPGA/112230313780
That’s a real dev kit for FPGA — inexpensive (US$ 34), slightly bigger than the Arduino Uno. The FPGA module (Xilinx Spartan 6) is in the centre, larger than Arduino microcontrollers. Surrounding the FPGA module are various switches and LEDs — very useful for debugging FPGA logic.
Since FPGAs are already mainstream, could we use them to create IoT devices that are more power-efficient than current devices based on microcontrollers?
Learning FPGA And Verilog A Beginner’s Guide Part 1 – Introduction
Thanks to the above FPGA tutorial by Numato Lab, I can now explain how FPGAs can solve problems in current IoT devices, specifically: power consumption and concurrency.
// Simplified Arduino sketch, based on https://github.com/lupyuen/unabiz-arduino/blob/master/examples/send-altitude-structured/send-altitude-structured.ino
void loop() { // Will be called repeatedly.
// Read the temperature, humidity from BME280.
float tmp = bme.readTemperature();
float hmd = bme.readHumidity();
// Compose the structured message, total 8 bytes.
Message msg(transceiver);
msg.addField("tmp", tmp); // 4 bytes for temperature
msg.addField("hmd", hmd); // 4 bytes for humidity
// Send the encoded structured message to Sigfox cloud.
msg.send();
// Wait a while before looping. 10000 milliseconds = 10 seconds.
delay(10000);
}
Why are microcontrollers bad for IoT?
Here’s an Arduino sketch that I use to teach IoT with the Sigfox network at Temasek Polytechnic. Our Arduino devices were deliberately designed to be as dumb as possible, so that we could put most of the processing logic in the cloud (AWS IoT and Ubidots), for easier updating. 99% of the student IoT projects follow the same pattern as above: Read → Compare → Send → Throttle
Most of the time spent is in the Throttle step — the 10-second delay between reading and sending sensor data. This is needed because Sigfox and other IoT networks don’t allow unfair, non-stop data transmission. Making the CPU wait 10 seconds is not efficient, but the Arduino CPU can only execute one instruction at a time. If the temperature or humidity fluctuates within that 10-second delay, it won’t be captured by the Arduino program.
I have experimented with various ways to overcome this concurrency limitation: Finite State Machine, Realtime Operating System (FreeRTOS), Rust + RTFM. But they make the programming unnecessarily complex, juggling multiple processing priorities with a single thread of execution.
Perhaps single-threaded microcontrollers are not meant to support multiple IoT sensors?
Why are FPGAs good for IoT?
What if we could read the temperature and humidity sensors simultaneously? The diagram above shows how it could work. No more inefficient waiting, and any sensor data updates are instantly transmitted, depending on the throttling settings. How could we make this happen with FPGA?
Think of FPGA as a very complicated electronic circuit with many, many electronic components. All components run simultaneously (limited by the speed of light) so parallel execution is a major benefit of FPGAs.
With this parallel execution we could read the temperature and humidity sensors continuously. We can’t send data to Sigfox continuously (due to the message limits) but we could compare the sensors against a certain threshold and send an alert.
Because we don’t spend time looping and waiting out the 10-second delay (and avoid executing so many idle instructions), FPGAs tend to be more power efficient for IoT. We process sensor data only when there are updates.
And because FPGAs inherently support parallel programming (instead of single-threaded programming in microcontrollers), we solve the sensor concurrency issue too.
// Verilog sample from https://numato.com/kb/learning-fpga-verilog-beginners-guide-part-2-modules/
module myModule(A, B);
input wire A;
output wire B;
assign B = !A;
endmodule
Programming an FPGA
Here’s the tricky part about FPGAs — programming an FPGA is really hard. You need to map all the input pins into output pins using logic modules. Shown above is a very simple FPGA program written in Verilog, a common programming language for FPGAs.
The program assumes there is an input pin A and an output pin B. The value of B is simply the inverse of A (!A means NOT A) . So logic 0 becomes 1 and 1 becomes 0. With an FPGA dev kit you could actually connect pin A to an onboard pushbutton switch and pin B to an onboard LED, and the LED will switch on and off when you press the button.
Now imagine hundreds or thousands of these Verilog modules running in parallel to read and send sensor data. It gets out of control quickly.
IP Cores from https://numato.com/kb/learning-fpga-verilog-beginners-guide-part-5-embedded-system/
Reusable FPGA Modules
There’s a way to manage this complexity. In Arduino we use libraries to reuse code. With FPGAs we use Intellectual Property (IP) Cores, Verilog modules that implement some complex function with submodules.
In the screen above you see a UART IP near the top right. This implements the serial input/output interface, which is complex because it requires a precise timer to send and receive the bits at the right bitrate. We will need this for our IoT device because we use UART to send messages with the Sigfox Wisol module.
Another example of IP: the I2C Interface. The sensor we are using (BME280) connects via an I2C interface, which requires a clock signal and a serial data connection. The I2C IP helpfully takes care of these complexities.
So here’s the tentative design of our FPGA-based IoT device, based on my limited knowledge of FPGA:
Numato Opsis FPGA-based open video platform: https://numato.com/product/numato-opsis-fpga-based-open-video-platform
Yes, FPGA is great for IoT and many other applications
IoT devices running on Sigfox and other low-power, wide area networks tend to have low complexity, since they operate on battery power and the processing logic runs in the cloud. So it makes sense that these IoT devices should eventually adopt FPGAs for lower power consumption. Also the parallel nature of FPGA helps to handle multiple sensors simultaneously. But to make this happen, we need a friendlier way to program and debug FPGAs.
FPGAs are appearing on the market for high performance applications. Here’s an FPGA device that can mix and capture HDMI video in realtime. (And it’s under US$ 500) FPGAs are also good for emulating legacy computers like Apple ][ and Commodore Amiga.
Machine Learning will benefit from FPGA too. The cars we drive are now using Machine Learning for detecting nearby objects. Complex Machine Learning models need powerful GPUs to perform the image processing. But a car’s electronics runs on a battery so we need to conserve power. That’s why the automotive industry is extremely interested in running Machine Learning algorithms on FPGAs instead of GPUs.
This has been a paper exercise in articulating why FPGA could be great for IoT, based on my teaching experience with low-power IoT devices. It’s the first of many steps in validating the use of FPGA for IoT. Next Step: Get my hands on a real FPGA dev kit and connect to sensors and Sigfox (via I2C and UART).
Postscript (nope, not the printable kind)
FPGA could solve the power and the concurrency issues for IoT devices. Here...
Within 12 hours of posting this article I have received lots of helpful comments — you can see them in the link above.
Thanks to Azri Jamil, we found a simpler FPGA tutorial based on the Lattice iCE FPGA and IceStorm open source tools:
Also as Jesse Teat has pointed out, I2C doesn’t allow two sensors to be accessed concurrently on the same bus. So the FPGA logic needs to poll the two sensors for updates. But this is still better than the Arduino design in which we won’t receive any updates during the 10-second delay. Lots to consider as I move ahead with the FPGA validation.
Note: The content and the pictures in this article are contributed by the author. The opinions expressed by contributors are their own and not those of PCBWay. If there is any infringement of content or pictures, please contact our editor (zoey@pcbway.com) for deleting.
Written by
