As I noted in an earlier What's Next blog, I am talking to some of the visionaries of the programmable industry about where we have been, what today's challenges are, and where we might go in the next several years. The idea is to provide the rest of us with a starting point for discussions, thoughts, and prognostications.
In my column last week, I included comments from Navanee Sundaramoorthy, embedded platform manager at Xilinx (this site's sponsor), about today's challenges with FPGAs/MCUs -- devices that combine hard MCU cores with programmable FPGA fabric. Today's blog covers some of Navanee's thoughts on what the future will look like for these devices. As usual, I have started a new message board, where we can continue the discussion.
Automatic algorithmic partitioning
Navanee sees a couple of key long-term goals that will provide dramatic new capabilities to the typical design. Most of these capabilities are centered on the concept of providing an architecture -- along with design and verification tools -- to allow algorithms to be partitioned automatically between processing resources (the MCU) and the FPGA's programmable fabric. These capabilities can range from simple extensions of current features to completely new design techniques.
One simple example would be letting the user write code without needing to define the various MCU peripherals. The software would decide if DMA, SPI ports, etc. were required, allocate hard instantiated peripherals, and then add others using programmable fabric as required. This would make it easier for a typical MCU designer to use the FPGA. An even more complex version might analyze the software and determine if in-line code could be replaced with peripheral functions. For example, an obvious code-based timing function could be replaced with a timer and interrupt implementation.
Navanee also described a more advanced approach that takes a higher-level view of the design. Many designs have a variety of control loops that implement key portions of the overall design. For example, he described a controller for an industrial production line. Some parts of the algorithm, like the human-machine interface (HMI), will run fairly slowly. Others, like connection to a real-time Ethernet communications system, will operate very quickly. Still others, like motor control functions, will operate at a midrange speed. It is convenient to think of these control loops as having different "loop times," which we may think of as the time in which a single decision needs to be made. Fast control loops may have only nanoseconds to make a decision. Slow loops, like an HMI, may have milliseconds, and midrange control systems might have a microsecond.
Next page >