You might have heard the term ‘FPGA’ thrown around every now and again. In several areas of the tech industry their use is growing -- particularly in automotive, aerospace, and medical applications.
To understand why they are becoming so popular we must go back to what they are: FPGAs, (Field Programmable Gate Arrays) are programmable logic devices that can have their functionality dictated by software (or as the engineers like to call this type of low-level software, firmware). The interesting thing about FPGAs is that this software can be altered or even replaced entirely while it is still in the circuit, meaning that its functionality can be drastically updated without taking apart or stopping whatever machine it is in.
To program these devices, most engineers use Verilog, a hardware description language that is pretty close to the metal. It is specifically used to model hardware, and even allows the developer to designate specific wires, gates, clock, etc. It is similar to C syntactically, and quite efficient. Since it allows programmers to be so specific with what the hardware does, engineers can employ FPGAs for a number of different tasks.
This means FPGAs are not just easy to upgrade, they are also extremely flexible. An FPGA’s programmable logic components can consist of a variety of different modules like logic gates (or logic blocks, i.e. lots of logic gates clumped together), memory elements (or memory blocks), and more. Since they are also all programmable, this means FPGAs can be adapted to deal with a huge number of applications.
Engineers know what those components are, so they can feel free to skip this paragraph. Not everyone is an engineer, though, and it’s worth understanding what these devices do in human-readable terms. FPGAs are called logic devices because they can perform logic functions -- this is thanks to their CLBs (Configurable Logic Blocks). These CLBs contain LUTs (Look-Up Tables), which allow the FPGA to perform logic functions without needing the board to be fitted with physical logic gates.
Logic gates are the essential building block of all digital circuits; they work by providing electrical outputs according to different electrical inputs. There are seven basic types of basic logic gates, and all of them have two inputs and one output (except one of them, which has only one input). Since they react on whether there is an electrical input or not, they work in binary -- and thus the inputs and outputs are interpreted as either 0 or 1. Sticking a bunch of them together allows engineers to create circuits capable of arithmetic functions, and from there they can go to the Moon (literally).
Logic gates and their uses.
Logic devices of some sort form the basis of almost all of the electronics that we use today, though obviously the functions that each performs varies wildly. FPGAs are not, however, the only logic devices in use today: there are also Complex Programmable Logic Devices (CPLDs) and Application Specific Integrated Circuits (ASICs). Each has different uses.
CPLDs are simpler than FPGAs, and are constituted of programmable AND/OR logic gate arrays and macrocells. This new component, macrocells, are the main building blocks of these devices, and contain complex logic operations (combinations of logical operators like AND, OR, etc.) and the logic necessary for implementing disjunctive normal form expressions (in a sentence, the grammar of how logic operations are written in code and how to decipher it into terms the CPLD can understand). CPLDs are smaller, simpler, and slower than FPGAs and are meant for simple applications like discretely fixing issues in wider hardware systems, especially since they are cheaper and less power-hungry than FPGAs.
ASICs are integrated circuits specifically built for a single application, and are extremely common in electronic devices. This is because they are much faster at specific tasks than FPGAs and also tend to be smaller and more power-efficient. In low volumes they are, however, much more expensive, and require high volume orders to make the per-unit price affordable since they are custom-designed chips.
Having gotten that out of the way, back to FPGAs. Occupying the middle ground between ASICs and CPLDs, they are both powerful enough and flexible enough to be used for a surprising amount of applications. Their flexibility and affordability makes them extremely useful for prototyping electronic devices, for example. Though ASICs are faster at specific tasks, their higher initial cost means they are usually reserved for use in final products, and FPGAs are used in their place to simulate what the ASIC will do. Codethink engineer (and FPGA expert) Ben Brewer recalled how, for one of his university projects, he was tasked with designing his own CPU; because of the prohibitive cost of manufacturing a single CPU, he instead opted to use an FPGA to create a ‘soft core’ processor that simulated what were to be the theoretical CPU’s functions. FPGAs have also been used for designing RISC-V soft core CPUs in a bid to promote the adoption of the architecture.
Applications for FPGAs extend beyond the prototyping stage. They are often used in situations where long-term maintenance and upgrades are essential to the machine they will be included in, and especially in those where upgrades must be done in the field while the machine is still in operation. This is why you will often find FPGAs in fighter jets, tanks, and satellites, used to connect the ASICs handling specific functions (i.e. RADARs on a fighter jet). Because FPGAs can be upgraded without disconnecting them from their circuits, entirely new functions can be added to vehicles (i.e. new cameras on the jet) easily and quickly via firmware updates. They are also seeing increasing use in automotive applications where developments in software can help improve the vehicle’s capabilities. This is especially the case in image recognition systems in cars, with FPGAs allowing the effectiveness and performance of these systems to grow through updates.
Due to the way that they are designed they also work well for parallel workloads (those in which several bits of data come at once, rather than in a steady single stream). That’s why we used them in our brain scanner project, as FPGAs could handle the data coming from a myriad of sensors all at once. This is also useful for debugging buses and serial interfaces.
So FPGAs are useful, although obviously how useful depends on common sense. In high volumes, sequential workloads, and applications where upgradability or flexibility aren’t a requirement, ASICs are simply the better choice. There are just some situations, though, where FPGAs make sense -- and it seems that the number of those situations are increasing. It is worth getting comfortable with how the logic devices work; they are likely come in handy for an engineering project at some point.
Images: CC BY-SA 4.0
FPGA board - https://commons.wikimedia.org/wiki/File:Icezum_Alhambra_Open_FPGA_electronic_board.png
Logic gates - https://www.instructables.com/id/Basic-Logic-Gates/
- Comic (Saturday Morning Breakfast Cartoons) - https://www.smbc-comics.com/
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Full archive