Louis walked the last flight of stairs to the roof with his gear in tow. Sebastian followed him and helped check the rigging. Louis got his bearings on the edge of the roof while Sebastian checked the wind one last time. The tell-tale strand of yarn on the handheld wind meter streamed backward and up as the LCD read the velocity. The perfect time was… Now! Louis pushed off and smoothly transitioned into his freefall form while pulling the release for the parachute. As his body raced toward the terminal velocity of 55 meters per second, the canopy inflated above his head. A powerful SNAP jerked him upward and he immediately grabbed a line to steer himself to the left, avoiding the building across the street and heading him toward his landing zone.
Sebastian walked inside and took the elevator to the bottom, arriving at the street less than a minute after Louis landed.
Clearly Louis isn’t participating in the extreme sport of BASE jumping (an acronym for Buildings, Antennae, Spans, and Earth) just to get to the bottom of the building faster than Sebastian. While BASE jumpers would probably be elated if a practical application for their sport suddenly materialized, they are content with the thrill they get from planning and executing such an exacting, death-defying feat of engineering and athleticism.
Very little in electronics engineering even approaches the realm of death-defying. Career-limiting is probably as close as we typically get. If you’re designing a high-end ASIC and you’re trying to avoid being the one whose mistake causes a re-spin, you may have a lot in common with a BASE jumper – triple checking everything before the critical moment to be sure that all is in perfect order.
In FPGA design, the closest thing we have to an extreme sport is partial reconfiguration. It may sound easy – leaving your FPGA operating while only a portion of it is re-configured with a new bitstream — but the reality of the situation is much more challenging. Partial reconfiguration is a bit like a surgeon trying to operate on himself while under partial anesthesia. It’s difficult to get the part you’re working on separated cleanly from the part that’s doing the work.
Partial reconfiguration has been something in the realm of novelty sport for FPGA designers for a long time. In engineering, however, there is a limit to how much progress can be made “just for the fun of it.” Eventually, you need the killer app – the problem that can be elegantly solved only with the trick you’re trying to learn. Without that, it’s like BASE jumping when there’s a perfectly good elevator that will do the same job with less risk and drama.
Software-Defined Radio (SDR) is a perfect example of the killer app for FPGA partial reconfiguration. In SDR, we need a compact, single-chip system with enormous computing power. Enigmatically, because of the processing performance demands, software-defined radio can’t be completely software-defined. In reality, most implementations require reconfigurable hardware to get sufficient performance (or sufficient performance within a limited power budget) to do the modulation and demodulation tasks required. This hardware acceleration is a perfect chore for FPGAs, because it requires exactly the thing FPGAs are best at – on-the-fly, in-system reprogrammability. Modems can be dropped into FPGA fabric and then replaced on a whim, requiring only a few milliseconds to complete the transition.
This doesn’t require partial reconfiguration by itself, of course. You could easily park an FPGA next to some other components and let the FPGA just do the heavy lifting for the compute-intensive bits. However, once you have an FPGA on the board, the temptation (for reasons of footprint, BOM cost, and power) is to move more and more stuff from the board into the FPGA. When you move the embedded computing system into the FPGA as well, you end up with a situation where the FPGA needs to keep running while just the modem part is reconfigured during operation. “AHA!” shout the partial-reconfiguration experts. “This is it! Put us in, coach!”
Historically, the only two FPGA vendors that will say the words “partial” and “reconfiguration” in the same sentence are Xilinx and Altera. Even those two always say it with a look of trepidation, as if the disclaimer sheet were longer than the datasheet, and the lawyers would be following shortly to make sure that anyone attempting this at home would sign a waiver. Even in those cases, partial reconfiguration is usually restricted to special-terms situations like changing a PLL counter or updating internal memory contents. Altering some arbitrary block of LUT fabric with a completely different and unknown bitstream is the ultimate challenge.
Xilinx has proceduralized the near-impossible by deploying an “approved” design flow for partial reconfiguration centered around their PlanAhead tool. Using PlanAhead, you pre-define a physical area of the FPGA that you want to set aside for dynamic reconfiguration while the device continues to operate. In your design, you insert special bus modules between the parts of your design that need to be swapped out. These parts are called “Partial Reconfiguration Modules”, or PRMs. You then follow a special design flow that generates netlists for not only the primary design, but also separate netlists for each PRM that will allow the creation of bitstreams for the primary configuration (for the static logic) as well as for subsequent partial reconfigurations. The design tools have to make sure that none of the static logic depends on anything inside the protected zone for reconfiguration. You wouldn’t, for example, want wiring for the static section to go running through the reconfiguring zone and be interrupted during the transition process.
Does all this sound pretty tricky? It is, and we’ve just scratched the surface here. Luckily, there are smart people out there doing a lot of the dirty work for us for special applications like SDR. This week, Xilinx and Thales demonstrated a partially-reconfigurable FPGA-based architecture for SDR using a single chip. The solution implements an SCA- (Software Communication Architecture) compatible environment for military radios. A single-chip FPGA solution obviously helps with the size, weight, and power (SWAP) issues inherent in handset design.
Xilinx also offers a development kit called the Joint Tactical Radio System Software-Defined Radio Development Kit (would that be the JTRSSDRDK?) that helps designers manage the complexity of partial reconfiguration for building systems similar to the one being demonstrated. While the partial reconfiguration purists may balk at the idea (it’s a little like having a turnkey automatic system that lets just anybody BASE jump safely), the complexity of the FPGA design task can be greatly simplified by the dedicated development kit, reference designs, and available IP.
Perhaps in the future we’ll see more killer apps for extreme FPGA engineering feats like partial reconfiguration. Until then, those of us not in SDR will just have to be content with pushing the design envelope just for the fun of it.
