Wednesday, October 11, 2006

why reconfigurable computing hasn't caught on yet

Most companies that wish to champion the next great paradigm shift to reconfigurable computing fail because they are only seeking to make hardware. They will try to attract developers by listing off potential applications for their hardware and reasons why their chip is going to take over the world. Companies that really are headed for broke fast will try to differentiate their reconfigurable technology from FPGAs on the basis of rate of reconfiguration or granularity of elements. Inherent in this differentiation is the belief that hardware is the limiting factor in reconfigurable computing. Configurable computing already exists in the form of FPGAs (I differentiate configurable from reconfigurable based on the rate of reconfiguration). Do startups really think they can pull a fast one against Xilinx by creating a market for rapidly reconfigurable hardware out of nowhere and before Xilinx can react?

The problem is that reconfigurable computing isn't a hardware problem. It's a software problem and it's a really big and hairy software problem too. There's no clear starting point either: part of the software problem is even just identifying which problems need solving. Most articles about "The Next Big Thing in Computing" have a skeptic keenly observe that tool support for reconfigurable computing is lacking. Lacking tool and system standards we are unlikely to truly produce any "next big thing."

So several companies have come along to deliver compiler tools to make development easier in some way or another. These companies fair better since they can gain traction without enormous expenditure. But reconfigurable computing still hasn't made its promised impact. This is because tools are only a small slice of the software problem. What we have is a chicken and egg problem: do the tools create the demand for applications or does demand for applications create the tools? The real software problem is to produce an important application that relies on reconfigurable computing technology. Driving demand for reconfigurable computing applications will have the effect of growing the toolset for developing such applications.

This feedback is nice, but it cannot be forced by pumping up compiler tools alone. Without substantial attention put into runtime environments and user interfaces it is unlikely that reconfigurable computing applications will take off. If you want to know how I think I can overcome these barriers, please email me.

1 comment:

raja neogi said...

I partially disagree with you:

virtual machines (primarily emulation technology) running on the physical machine (perhaps a multi-core SOC) or fabrics (like Xilinx parts) have been written to solve the reconfiguration problem, but reconfiguration is worthless if it is not fast enough to support the application specific needs (BTW this can vary widely from say cognitive radio networks to video networks).

During reconfiguration, data-flow needs to stop, as the computation kernels are being morphed (this could be either the VM or VM code or both). This morphing entails movement of instruction streams, latency for which is hardware dependent. Moving instructions from say DRAM to SRAM, is cheaper than movement from flash, but dedicated infrastructure could speedup the kernel morphing. There is a need for the fabric to be re-configuration ready.

The next step in reconfiguration is to support dynamic reconfiguration -- for example, a 4-stage pipeline processing just uses transistors needed to work out the worst case stage, primarily to reduce power consumption. To support this model, the cost to reconfigure should very small, implying the makeup of the physical machine cannot be ignored.

The summary is that characterizing reconfigware is application dependent and influences the SW environment quite a bit.