As I mentioned in an earlier column, I am talking to some of the visionaries of the programmable industry to get their ideas on where we have been, today's challenges, and how the future will look. The idea is to give the rest of us a starting point for our own discussions, thoughts, and prognostications.
In last week's blog, I discussed the challenges faced by low power in today's FPGAs. That discussion was based on my conversation with Arif Rahman, an IC design architect from Altera. Today's column, which covers the future of FPGAs and low power, is also based on my conversation with Arif, along with a liberal dose of my own musings.
Learning from MCUs, ASSPs, and ASICs
One of the good things about developing FPGAs is that we can extrapolate from a body of knowledge from the ASIC, ASSP, and processor worlds. Arif and I talked about some of the trends that ASICs and processors have already mapped out, which can be used to improve FPGA power efficiency. Here are my thoughts on what we might see in the future based on the products Arif identified as the low-power FPGA "trend setters": MCUs, ASICs, and ASSPs. (See: Ask Max: ASICs vs. ASSPs vs. SoCs vs. FPGAs.)
ASSPs and processors have stayed ahead of the power curve by using "hardened" implementations of common functions, and FPGAs have followed this path. We can expect more hardened functions that will probably be oriented by market segment to keep device costs down. (Communications will have a different set of hard functions than video processing, control, networking, etc.) Look for FPGAs to replace ASSPs in all but the highest-volume applications. They may not replace cellphone processors for a while, but we might be surprised at what may be achieved by using the reconfiguration capabilities of FPGAs to their fullest extent. ASSP vendors may turn into application specialists via differentiating FPGA IP and not 100 percent "hard" devices.
One of the best features of MCUs is the low-power modes (Stop, Sleep, Snooze, etc.) that can turn off large portions of the device and wait for a wakeup event to occur. Similar systems could be implemented in FPGAs, perhaps by turning off most of the blocks and leaving a very small section to wake up. Various levels of functionality could be defined as on or off depending on what is needed. To make management easy, you might define a few views of the design and require various conditions to turn on a particular view. A more complex implementation might even have different logic configurations that get swapped in and out (much like a virtual memory system for a processor) as functions are time shared with the available logic fabric.
Next page >
Tweet This
