I’m a long-time microcontroller (MCU) user and enthusiast, with a particular interest in the use of low-overhead modules in enabling greater communication and interface capacity than that traditionally achieved by an individual chip. Some of my favorite personal projects include developing an MP3 player, an alarm clock, a wireless ground moisture control system, a dog activity monitor, and a Bluetooth low energy wireless prosthesis control. In all of these, the MCU provided both ease-of-use and the essential capabilities for gathering information and issuing simple commands.
Recently, I was given a project that not only required me to make the transition to the intimidatingly expansive FPGA—Field Programmable Gate Array—but also required me to move into the much larger and far more capable ARM cortex. This was a place outside the safety and ease I was accustomed to in the mBed environment. In this four-part blog series, I’ll examine how I translated, transferred, and transitioned my existing knowledge and experience with MCUs into the FPGA development environment. In Part 1, we’ll begin with some advantages and disadvantages of FPGAs, introduce the Terasic DE10 Nano development kit, and look at the role of intellectual property in FPGA design planning.
If you’ve been developing projects with MCUs, you’ve probably found that the learning curve is not too steep, that tools are readily available, that development and revision processes are straight-forward, and that designs are very portable. You’ve probably also found, though, that their processing can be limited in terms of complexity, speed, and established interfaces. My relatively simple, personal projects up until the point of my transition were ideal for MCUs because they were neither complex nor had significant processing needs.
FPGAs are integrated circuits that contain logic elements—with programmable building blocks already built in and designed to be super flexible yet highly capable. For example, they can emulate microprocessors or RAM to boost performance, adapt to changes by allowing new standards or algorithms to be implemented, and add communication interfaces—all of which help reduce total system costs and extend product lifecycles. The downside to this capability is that the learning curve is pretty steep. And for MCU developers, the learning curve is compounded by a shift in fundamental methodology in I/O and coding. Instead of a single port and voltage or, likewise, instead of a single port and protocol, FPGA development allows for multiple ports with multiple voltages, can use any protocol, and processes in parallel.
Fortunately, I discovered the Terasic DE10 Nano dev kit, which is built around the Intel Cyclone® V SoC. The Intel Cyclone® V SoC combines FPGA fabric around an Dual-Core ARM Cortex A9. This makes the capabilities of the FPGA accessible by building in several support components, including display and communication ports, buttons and switches, pin mappings and a quick configuration tool, a JTAG debugger, and well-documented examples and guides from both Terasic and Intel®.
When planning for MCU developments, I would determine what interfaces were needed (i.e., SPI, I2C, Wi-Fi, and so on) and then make an informed selection based on voltage, pin counts, communication interfaces, library support, and price. With an FPGA, almost every interface is now possible, but the limiting factor is the number of logic cells, which are used to create the functionality of the port, soft core MCU, or memory element. The trade-off, then, is that the higher the logic cell count, the more capable the FPGA and… the higher the FPGA cost. Although FPGAs usually have a higher initial cost, they offer huge potential power and space savings—as they can combine multiple components into a single component.
I found myself at a crossroads: How will I know how many logic elements I will need for my design? The answer is dictated by the needs of the FPGA intellectual property—called IP, which consists of protocols, functions, my code, and specific tasks that are normally performed by an external module. Almost all FPGA metrics are broken down into logic elements, registers, and total I/O banks (which are the differentiating units of measure for each chip). Here is the definition of each:
The idea of IP’s importance initially escaped me because I hadn’t yet grasped the fact that it described the ability to stand in place of a physical real-world device like an MCU, communications controller, or something I would otherwise use another piece of silicon for.
Out of the box, the DE10 Nano uses the FPGA layer primarily as a very low latency I/O expansion, as shown in Figure 1. All of this comes together to hit another design feature of an FPGA: It can contain most of a PCB in a single chip and, thereby, allow much easier flexibility in future designs.
Figure 1: Terasic DE10 Nano Cyclone V FPGA and hard processor system (HPS) interface layout. (Source: Terasic)
Most of the low-level I/O is controlled and interfaced through the FPGA. This offers the advantage of lowering CPU time spent waiting on a low-level I/O change. This also allows for conditioning or alterations before delivery to the hard processor system (HPS). Of course, what perfect sense this makes because the Cyclone V FPGA is a fabric with a design that can expand interface capacity, accelerate performance, and boost the capability of any paired HPS. In this case, as Figure 2 shows, the HDMI interface is a non-native interface to the HPS, so there aren’t many MCU resources developed for it.
Figure 2: FPGA and HPS interfacing setup. (Source: Terasic)
At first look, I notice several positive aspects:
Overall, I’m liking the FPGAs and find the expansion and acceleration capabilities to be intriguing; however, I wonder about their limitations. How fast can they go? What protocols can they support? How many LE will they consume? Overall, the IDE is simpler than others that I have used and includes amazing documentation to begin. The hardware seems extremely robust and capable, and I’m devising a project that I think will test the limits of the hardware on this board.
What will the project be? And how do we test the hardware limits of this board? Stay tuned for Part 2 of this blog series!