feature article
Subscribe Now

FPGA BASE Jump

Partial Reconfiguration for SDR

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. 

Leave a Reply

featured blogs
Dec 2, 2024
The Wi-SUN Smart City Living Lab Challenge names the winners with Farmer's Voice, a voice command app for agriculture use, taking first place. Read the blog....
Dec 3, 2024
I've just seen something that is totally droolworthy, which may explain why I'm currently drooling all over my keyboard....

featured video

Introducing FPGAi – Innovations Unlocked by AI-enabled FPGAs

Sponsored by Intel

Altera Innovators Day presentation by Ilya Ganusov showing the advantages of FPGAs for implementing AI-based Systems. See additional videos on AI and other Altera Innovators Day in Altera’s YouTube channel playlists.

Learn more about FPGAs for Artificial Intelligence here

featured paper

Quantized Neural Networks for FPGA Inference

Sponsored by Intel

Implementing a low precision network in FPGA hardware for efficient inferencing provides numerous advantages when it comes to meeting demanding specifications. The increased flexibility allows optimization of throughput, overall power consumption, resource usage, device size, TOPs/watt, and deterministic latency. These are important benefits where scaling and efficiency are inherent requirements of the application.

Click to read more

featured chalk talk

Easily Connect to AWS Cloud with ExpressLink Over Wi-Fi
Sponsored by Mouser Electronics and AWS and u-blox
In this episode of Chalk Talk, Amelia Dalton, Lucio Di Jasio from AWS and Magnus Johansson from u-blox explore common pitfalls of designing an IoT device from scratch, the benefits that AWS IoT ExpressLink brings to IoT device design, and how the the NORA-W2 AWS IoT ExpressLink multiradio modules can make retrofitting an already existing design into a smart AWS connected device easier than ever before.
May 30, 2024
34,328 views