Courtesy: Mouser Electronics
When I started this project, I understood FPGAs benefits enabled developers to integrate a wide variety of functions into a single circuit then modify these functions down the line—making them reconfigurable and future-proof. But this flexibility led me to wonder: How should I handle interfaces with external components, wiring to interfaces, and the like? With the average design cycle for FPGA being two to three years, and considering the life span of current communications technologies like USB 3.0 to USB Type-C, I was boggled at how an FPGA could really be a benefit.
As I do with most MCU projects, I planned to start with example code and then build my own project out from a variety of examples. But with each example, I found I was less and less familiar and ended up more and more confused. The code was organized into object definitions and function calls, which were recognizable to this MCU guy, but some definitions went into timed higher-order functions and others were just there. The functions, as always, handled performing a task; however, some functions were dependent on others and some were not. The ones that were not called directly were still pivotal to code functionality, as I discovered by attempting to comment them out.
I was befuddled.
By doing “Intel FPGA Setup Cyclone V” searches, I decided to look at examples and “Setup & Go” trainings available on YouTube. As I looked through these trainings, I began to see a common theme (see Figure 1):
- A seemingly disconnected set of commands that were still functional, yet that seemed incomplete
- A complete lack of external modules or components that did not support the FPGA
With these observations, I went back to reviewing more sample designs and code, and I began to see where the Intel Cyclone V and the HPS FPGA architecture really came to prominence. Figure 1 shows the HDMI command set, which includes a bunch of uncalled portions of code. The code’s uncalled portions do not run in sequence but, rather, in parallel. They function much like callbacks activated by data from a higher-level controller in the HPS calling them. The compiler then adds the capability of passing information over to the MCU, and vice versa. All that’s needed to go between the controller and the MCU is coordinating definitions and a timing schedule.
I began to see the program flow was this:
- The Linux HPS portion grabbed the image.
- The Linux portion handed the OpenCV processing over to the FPGA.
- The Linux portion adapted the image.
- The FPGA received the raw image information and coded it for the HDMI interface.
This was a perfect example of using the strengths of both the HPS and the FPGA. The FPGA handled a lot of repetitive math and protocols, while the Linux and MCU portion handled the dynamic elements of the program. This really began to open my eyes to where an FPGA excels.
As I dug into similar MCU-only designs, I discovered the other advantages of an FPGA: It requires far fewer components, and it allows for a much less expensive and capable MCU to achieve very impressive results. For example, an MCU-only design would need a higher A52, or the like, to begin tackling image processing. A GPU would also be necessary to tackle graphics acceleration during processing and more RAM to achieve the entire design. Still, the end-result is a locked, limited upgradable module after the design is complete. With FPGA, the components reside in the same chip, so the production-level PCB design is simpler because it requires fewer component-to-component interfaces. The resulting module is still upgrade and flash capable.
The lightbulb going on over my head could probably be seen for miles around.
The benefits to using FPGA are more than just the ability to integrate a wide variety of functions into a single circuit, minimize interfaces, and modify functions down the line. The FPGA changed the way I think about adding external components to do a task to one that’s more efficient. Rather than thinking, “Perform step one, then two, then three,” I now think in terms of tasks: “Do A, B, C, and when B is done, do D.” Ahhh! The reasons for taking the time to go from MCU to FPGA development are now becoming more and more clear.
Stay tuned for Part 4 in this four-part series!
