Partial reconfiguration – it’s about time

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.

Consider:

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.

Advertisements

3 Comments

Filed under News Shmews, Reconshmiguration

3 responses to “Partial reconfiguration – it’s about time

  1. You’re not the only one who thinks that Incremental Synthesis and Dynamic Partial Reconfiguration will lead to a Renaissance in FPGA design. I just don’t think Altera has it yet. My very first blog post from 2006 is basically summed up in your point: “[FPGA vendors] can only think of their devices as the poor-man’s ASIC. And their tools as a poor-man’s EDA.”

    I first witnessed a Virtex-II-Pro FPGA getting dynamically partially reconfigured while I was an intern at Xilinx in 2006. I remember having a lunch conversation with the CTO of Xilinx about dynamic partial reconfiguration and I wondered why this wasn’t a major focus of tool research. You would think that if customers were clamoring at their door asking for it, then it would be supported already. It is of course, a technology that must be supplied before it is demanded. It is the faster horse like Henry Ford’s customers would have asked for.

    Back in 2006 we knew that in order to support the hybrid multicore/FPGA computing over the HyperTransport bus like DRC and XtremeData were doing, then we would need to keep the HyperTransport bus interface alive while we reconfigured the FPGA for the particular task. Certain vendors like Celoxica avoided the problem by having an interface FPGA separate from the main reconfigurable computing device. The early version of the DRC system did not support partial reconfiguration and since the HT bus interface died when you reconfigured, the entire system needed to reboot in order to run a new configuration: this was a deal-breaker for my application.

    Appliance vendors will provide some interface “vendor logic” with some dynamically reconfigurable “user logic.” Tools like ImpulseC will gain a lot of relevance in markets where a vendor want to provide a 4GL API for the appliance that compiles into ImpulseC that compiles into the “user logic.”

  2. I’m looking forward to a time when you could effectively write a kernel for such a device. So that you could allocate space to different “processes” and so that FPGAs would be able to take the place of traditional CPUs.

  3. Srikanth

    Couldn’t agree with you more. I believe partial dynamic reconfiguration will user in a new age of computing. In fact I’m betting my career on it. It is my dream to work on a system like what Daniel talks about above.
    Any chance of employment in your company?

    btw I’m working in CHREC @UF

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s