India - Flag India

Please confirm your currency selection:

Indian Rupee
Incoterms:FCA (Shipping Point)
Duty, customs fees and taxes are collected at time of delivery.
Payment accepted in Credit cards only

US Dollars
Incoterms:FCA (Shipping Point)
Duty, customs fees and taxes are collected at time of delivery.
All payment options available

Bench Talk for Design Engineers

Bench Talk


Bench Talk for Design Engineers | The Official Blog of Mouser Electronics

Introducing an MCU Guy to FPGA: Part 3 Mouser Staff

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.

Figure 1: The HDMI command set, which includes a bunch of uncalled portions of code.

I began to see the program flow was this:

  1. The Linux HPS portion grabbed the image.
  2. The Linux portion handed the OpenCV processing over to the FPGA.
  3. The Linux portion adapted the image.
  4. 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!

« Back

Mouser Electronics – a wholly-owned subsidiary of Berkshire Hathaway Inc. – is one of the industry's fastest growing global catalog and online semiconductor and electronic component distributors. Mouser is a company dedicated to supplying design engineers and buyers with the newest products and leading-edge technologies combined with unsurpassed customer service and worldwide support. With a keen focus on design engineers and buyers demanding the latest products, Mouser is redefining customer-focused distribution.

All Authors

Show More Show More
View Blogs by Date