Project update 1 of 5
Since we launched the QuickFeather campaign one week ago, we’ve received some thought-provoking questions on why we architected our EOS S3 device to include both a Arm Cortex M4 MCU and an embedded FPGA (eFPGA). Many of you have already used MCUs and FPGAs discretely on a PCB, so the question becomes, "Why integrate them into the same chip?" There are many answers to that question, that we will seek to clarify below.
First, it’s important to acknowledge that running software on a processor is THE most flexible method to implement any function in a system. It’s typically written in C or some higher-level language that eventually ends up being compiled for a processor core. But while software on a processor is the most flexible, there are some potential pitfalls. The software:
Processors are usually chosen early in the design phase, when the system architecture is somewhat fluid. Once the scope of the processor requirements is understood, a specific MCU, and perhaps a discrete FPGA could be chosen. Away we go with the PCB design!
Enter the dreaded Product Requirement Change… If the change is large enough, the project may not be feasible with the same components anymore. Historically, designers could then more to a different MCU or different FPGA alongside their MCU. Since we (QuickLogic) wanted to ensure we could adapt our MCU for different end markets and application use cases without going through the costly and time-consuming mask-spin, we chose to include eFPGA on the same die as the MCU. In doing so, our chip becomes more adaptable; think agile hardware!
Across the numerous designers who have used the EOS S3, there are a two common use cases for the eFPGA:
Let’s dig into them further.
DSP functions (e.g., filters) are a foundational element of many edge applications such as audio signal processing and voice recognition. In lieu of running all of those DSP functions as software on a general-purpose processor, certain functions can be offloaded to or accelerated on an eFPGA with tightly coupled DSP blocks. The benefit is often lower power, and a freeing up of precious MIPS on the embedded processor. As product requirements change (think about how often implementations change in the age of AI), it provides flexibility to experiment with different partitioning of hardware/software for the best system tradeoffs. It’s possible to do this with discrete MCU/FPGA architectures, but you don’t get nearly the benefit afforded by a tightly coupled architecture.
Let’s move to our second common use case. It doesn’t get the hype, but that shouldn’t diminish its value to a system. As system architectures are assembled, careful attention needs to be paid to the I/O connecting the chips on a board. Some protocols require very strict timing in order to function correctly, which can be extremely challenging to implement in software. Processors get busy, latency becomes unpredictable, and I/O timing falls apart. Historically, FPGAs have been use for these applications, to completely offload the mundane, yet critical, protocol and precise timing of certain I/O standards. By using an eFPGA for these implementations, you get the value of precise timing with the benefit of eliminating the timing delays and costs associated with adding other components. I/O standards aren’t static either; they evolve over time. Wouldn’t it be nice if you could evolve your hardware with the standard by changing Verilog instead of changing PCBs? eFPGA enables that.
For technical questions related to QuickFeather and EOS S3, please refer to QuickLogic’s community support forum. While there, you can search for previously submitted user questions, post a new question, or, even better, contribute an answer or suggestion to make our 100% open source initiative even better.