Altera today announced that its next-generation, 28nm devices will support partial reconfiguration. This means that Altera FPGA users will now be able to update small portions of an FPGA device, rather than having to re-synthesize, re-map and reprogram the entire device every time the application changes.
Xilinx has supported this feature for quite a few years, but has never made it a mainstream, supported feature of their ISE Design Suite development tools. However, in a recent email update to its customers, Xilinx announced with almost no fanfare that, in version 12 of the Xilinx tools, this important capability would finally be given its proper status as a supported feature. Perhaps the marketing department at Xilinx heard rumors coming from the other side of San Jose?
Corporate intrigue aside, this is an important piece of news. Why? Because software application developers first investigating FPGAs are surprised – even shocked – to learn how long the iteration times are for programming and debugging FPGA applications. And the larger the FPGA is, the worse the problem becomes.
For most software developers, being faced with the equivalent of a two, three, or even eight hour iteration time for compile-link-test is completely unacceptable, no matter how much potential increase in performance there may be.
And if, at the end of that long iteration time all the programmer has is a non-working, difficult-to-debug bitmap and a thousand-lines long report filled with hardware-esque warning messages? Then forget it. They might as well go use GPUs and CUDA.
So, why has it taken so long for this seemingly obvious feature to become mainstream? One can only assume that Xilinx and Altera management, their chip architects, and perhaps even their tools developers are hardware engineers first, and software engineers second. Perhaps they can only think of their devices as the poor-man’s ASIC. And their tools as a poor-man’s EDA.
Reliable, vendor-supported partial reconfiguration, including dynamic run-time reconfiguration, has the potential to solve so many problems for software application developers, and to broaden the market for FPGAs.
Partial reconfiguration allows developers to iteratively recompile, re-synthesize, re-map and re-test a specific portion of the FPGA in just a few minutes, rather than a few hours. This in itself is a huge benefit. Instead of having to set up elaborate, hardware-oriented simulations to verify correct behavior before hitting that compile button, you can just try it out, again and again, in the same way you would when developing software. Indeed, this method of design was predominant for FPGAs in the 1980s and early 1990s. But as device densities have grown, iterative design-and-test methods have become impractical. That was good for the hardware simulator business, but bad for software developers.
Run-time reconfiguration allows certain parts of the FPGA to remain intact and functioning, for example the I/O processing, while other parts are being updated on-the-fly. Need to change the filtering of a video signal to respond to a change in resolution? Wham, it’s done, and so fast the viewer doesn’t even see a flicker. Want to change the FPGA’s function without causing a system reboot? How about leaving the PCIe endpoint alone and just changing the core algorithm?
Dynamic reconfiguration can increase the effective size of an FPGA. Loading of partial bitmaps at run-time allows the capacity of these devices to grow in the dimension of time. If you don’t need all the hardware capabilities you have programmed into your FPGA all the time, then use dynamic reconfiguration to swap hardware modules in and out as needed. Use reconfiguration to do more, with less.
Partial reconfiguration opens up new FPGA markets. Using partial reconfiguration, the vendors of FPGA-based platforms for specific types of applications – for financial transaction processing and automated trading, for example – could provide a “minimally programmable embedded system” in which most of the FPGA logic is pre-designed, pre-optimized and locked down, while a small portion in the middle is left available for end-user customization. This potentially opens up whole new application domains that were previously not available for FPGAs; applications in which the platform vendor and the end user both have unique domain knowledge, and have their own critical IP to protect.
Again, these capabilities are not really new; the Xilinx partial reconfiguration features have been used successfully, for years, in domains such as software-defined radio. What’s changing is that partial reconfiguration is finally becoming officially supported. With uncertainties about its future and its supportability reduced, software and platform vendors will now begin using these features to enable new programming, debugging and operating features into their own products.
It’s about time.