In this blog, I'm continuing my mini-series on the future of FPGAs and how they support the implementation of operating systems (OSs) and real-time operating systems (RTOSs). (See also Part 1 of this miniseries.)
In this post, we'll discuss today's challenges, which will lead us into my next blog on future trends. This series has a focus on the hardware aspects of OS/RTOS support. In a future series, I hope to focus more on the software side, perhaps by interviewing one or more third-party OS and/or RTOS vendors. Please let me know who you think would make good interview candidates.
Previously, we discussed the history of FPGAs with on-chip MCUs (either soft or hard core implementations) and the use of simple operating systems and real-time operating systems with Raj Nagarajan, a Product Manager for the Xilinx Zynq Family. Raj is currently responsible for developing key partnerships with embedded tool and OS vendors, so he has an excellent understanding of the features needed to simplify OS and RTOS implementations on FPGAs.
As we noted in my last blog, FPGA designers started out by using on-chip soft MCU cores as large state machines, and evolved to requiring higher-end features like simultaneous execution threads, leading up to full-on RTOS and OS capabilities.
Satisfying existing MCU customer demands
As we continued our discussion, Raj explained that a customer shift is currently underway, which brings a new set of challenges to FPGA manufacturers who offer MCU capabilities on their devices.
It seems there is a new set of customers who are interested in using FPGAs with MCU capabilities, but who are not FPGA-savvy. These customers expect a traditional MCU design flow, but until recently, the design flow offered by FPGA vendors typically required extensive hardware configuration.
Often, the user needed to define the MCU, sometimes at the fundamental architecture level. For example, the connection of the MCU to the instruction and data memory buses could be customized using a shared bus or separate buses. This level of customization extended to memory size, memory location (on-chip or off-chip), and memory implementation.
Peripherals could also be customized, and needed another level of configuration. The advantage of providing users with a wide range of options was that this allowed them to tailor their implementation for their target application. The disadvantage was that this created unnecessary complications for a user who just wanted a simple MCU to program. Traditional FPGA designers viewed this configuration capability as a strength, but it created a big adoption barrier for traditional software-oriented MCU designers.
Next page >
Tweet This
