1. Event title here 11/21/2007 Partial Reconfiguration Chris Conger PhD Student & Research Assistant CHREC Center, University of Florida 11/21/2007

2. 2 Outline Introduction History of Partial Reconfiguration PR Design vs. Regular Design Performance Impact CHREC Research References

3. 3 Introduction What exactly is Partial Reconfiguration (PR)?  Reconfiguring part of an FPGA, while the rest remains configured, active, and un-interrupted Most (e.g. almost all) FPAG designs are made for full reconfiguration Relative to FPGAs in general, partial reconfiguration is relatively new capability (~2000)  Different design style, HDL coding rules for designing partially-reconfigurable architectures More “low-level” than non-PR designs, designer is very involved in placement of modules and primitives Unique rules for code structure, components specific to PR

4. 4 Introduction What are the benefits of PR?  Critical modules may remain un-interrupted during reconfiguration of a different part of design Network connections do not need to be broken and re-initialized XD1000 platform is perfect example of needing this capability  Time-multiplexing of a device Smaller FPGA can provide same functionality as much larger device, assuming different applications are time-independent Reduce power, space, cost by using smaller device  Reduced configuration overhead Configuration storage costs and configuration times reduced May be important/valuable for some HPEC applications  Enhanced fault tolerance capabilities With finer-grained reconfigurability, new options for fault tolerance are made possible Configuration scrubbing, adaptable redundancy, continuous Built-In Self Test (BIST) for permanent faults (and reconfiguration around those found)

5. 5 Introduction So what’s the problem? Why has PR not taken off?  Merciless design flow… application designers and scientists already don’t like VHDL/Verilog, PR design is even more low-level

6. 6 Introduction So what’s the problem? Why has PR not taken off?  Merciless design flow… application designers and scientists already don’t like VHDL/Verilog, PR design is even more low-level  Requires special patch to Xilinx’s design software (ISE), not yet publicly released

7. 7 Introduction So what’s the problem? Why has PR not taken off?  Merciless design flow… application designers and scientists already don’t like VHDL/Verilog, PR design is even more low-level  Requires special patch to Xilinx’s design software (ISE), not yet publicly released  Despite apparent benefits, difficult to identify applications or systems which stand to benefit from the capabilities offered through PR

8. 8 Introduction So what’s the problem? Why has PR not taken off?  Merciless design flow… application designers and scientists already don’t like VHDL/Verilog, PR design is even more low-level  Requires special patch to Xilinx’s design software (ISE), not yet publicly released  Despite apparent benefits, difficult to identify applications or systems which stand to benefit from the capabilities offered through PR Necessity was not the mother of this invention!

9. 9 History of Partial Reconfiguration PR is pretty much only supported in Xilinx FPGAs  Actel supports it as well, but PR on Actel devices has not been researched  Altera chips do not support PR PR has technically been possible in Xilinx FPGAs since the release of the Virtex-II families in early 2000’s  Until recently, practical challenges/restrictions made PR infeasible, even though technically possible  With the release of the Virtex-4, and now Virtex-5, these design constraints have been greatly relaxed

10. 10 History of Partial Reconfiguration To make PR usable, there must be support for PR design built into vendor development tools  Earliest PR attempts involved hand placement and routing of designs… you DON’T want to have to do that for a whole design  Again until recently, Xilinx saw no motivation to put forth effort to add support for PR design So what changed?  In a nutshell, the emergence of the Software-Defined Radio (SDR) market  SDR stands to benefit greatly from combination of two PR benefits: Time-multiplexing of a device Un-interrupted operation of static portion of design  U.S. military and defense contractors see SDR as critical technology for future of warfare Dept. of Defense has deep pockets = motivation for Xilinx  Xilinx finally engineered a workable design flow for PR within their standard ISE development environment

11. 11 History of Partial Reconfiguration Academic research related to PR  Despite the increasing feasibility and publicity of PR, most uses of PR to-date have been restricted to academic circles  On top of that, most academic research centered around slightly older devices, Virtex-II and Virtex-II Pro  Here is a list of general topics considered by research groups outside of UF investigating PR Architecture research, case studies  Overcoming practical challenges and constraints  Demonstration of PR in different use-cases Run-time management of PR systems Design tools Fault tolerance, fault injection

12. 12 PR Design vs. “Regular” Design Now for a little “nuts and bolts” In general, differences can be summed up as follows:  HDL files must be written/structured a certain way  Must follow Xilinx’s modular design flow  Must use special patched version of ISE for implementation flow (any synthesis tool is fine)

13. 13 PR Design vs. “Regular” Design HDL coding rules  Top-level HDL file can ONLY contain: Clocking primitives (DCMs, BUFGs, etc…) Input/Output buffers (IBUF, OBUF, IOBUF) Bus macros (more info in a bit) Black-box instantiations of main modules  User Constraints File (UCF) MUST include: Area constraints for each main module  SLICE_XY  RAMB_XY  DSP48_XY Placement constraints for ALL clocking primitives instantiated in top- level HDL file  Module HDL files (all but top-level) CANNOT include: Input/Output buffers Clocking primitives Bus macros

14. 14 PR Design vs. “Regular” Design Synthesis, implementation flow differences  Top-level HDL file and each main module are synthesized separately

15. 15 PR Design vs. “Regular” Design Synthesis, implementation flow differences  Top-level HDL file and each main module are synthesized separately  Scripts are called to run the implementation flow on synthesized modules

16. 16 PR Design vs. “Regular” Design Synthesis, implementation flow differences  Top-level HDL file and each main module are synthesized separately  Scripts are called to run the implementation flow on synthesized modules “Base” design implemented first (through place & route) Each partially-reconfigurable module (PRM) is implemented individually Special timing verification needs to be performed to ensure all possible combinations of base design and PRMs meets timing constraints After timing verification, base design and PRMs are merged to generate full and partial bitstreams

17. 17 PR Design vs. “Regular” Design So what was that “bus macro” thing you mentioned?  When signals cross boundary between modules, need to be “anchored” at known locations  These anchor points are provided by primitives called “bus macros”  Pre-synthesized netlists downloaded from Xilinx, instantiated as black box components in design Bus macros can be synchronous or asynchronous  E.g. clocked vs. non-clocked  Highly-recommended to use synchronous bus macros whenever possible for performance

18. 18 Practical Challenges of PR Design Before Virtex-4s:  Partially-reconfigurable regions (PRR) were entire vertical columns of FPGA  Static signals could not easily pass through PRRs  Combination of these two main restrictions made PR design very impractical Virtex-4 and later:  PRRs can be rectangular in shape, do not need to span entire device Configuration frame granularity of 16 vertical CLBs  Static signals can pass through PRRs

19. 19 Two Different Flows Special-purpose system design  Designer can take advantage of advance knowledge of module requirements, heuristically optimize size, shape, and location of all PR regions; generate base and all partial bitstreams at same time  Good opportunity to automate this design flow through design tools Multi-purpose system design  System design with intention of re-use for multiple applications; “base” design implemented once, separate from PR modules (which are created as needed)  Goal of this flow is to maximize design reusability, achieve some savings in qualification or verification cost of new designs (as well as development time, potentially); isolate application designers from board-level issues Special-purpose system designMulti-purpose system design

20. 20 Example Use-Cases of PR Embedded PowerPC system  PowerPC, CoreConnect bus, majority of design is static  One or more co-processor modules/bus peripherals are partially reconfigurable

21. 21 Example Use-Cases of PR Fault tolerant architecture  Configuration scrubbing, self-reconfiguration  BIST for permanent faults

22. 22 Conclusions PR, while an exciting and relatively new capability, still needs more research to help illustrate its usefulness to industry CHREC Center at UF is active in PR research with latest FPGA devices  Using PR to provide reconfigurable fault tolerance (RFT)  Design tool research, making PR more attractive to non- hardware designers If you are interested in PR research, contact myself, Dr. George, Dr. Gordon-Ross, or Dr. Lam

23. 23 References J. Emmert, C. Stroud, B. Skaggs, and M. Abramovici, “Dynamic Fault Tolerance in FPGAs via Partial Reconfiguration,” in Proc. of IEEE Symposium on Field Programmable Custom Computing Machines, April 17-19, 2000, pp. 165-174. E. Johnson, M. Wirthlin, and M. Caffrey, “Single-Event Upset Simulation in an FPGA,” Proc. of International Conference on Engineering of Reconfigurable Systems and Algorithms (ERSA), Las Vegas, Nevada, June 24-27, 2002, pp. 68-73. E. Johnson, “Estimating the Dynamic Sensitive Cross Section of an FPGA Design Through Fault Injection,” Masters thesis, Brigham Young University, August 2005. A. Donlin, “New Tools for FPGA Dynamic Reconfiguration,” Xilinx research presentation, December 6, 2005. M. Defossez, “Embedded Computing and Partial Reconfiguration,” Xilinx research presentation, May 2005. N. Shirazi, W. Luk, and P.Y.K. Chung, “Run-Time Management of Dynamically Reconfigurable Designs,” in Proc. FPL98, LNCS 1482, Springer, 1998, pp. 59-68. M. Huebner, T. Becker, and J. Becker, “Real-Time LUT-Based Network Topologies for Dynamic and Partial FPGA Self-Reconfiguration,” in Proc. of 17th Symposium on Integrated Circuit and Systems Design, Sept. 7-11, 2004, pp. 28-32. P. Sedcole, B. Blodget, J. Anderson, P. Lysaght, and T. Becker, “Modular Partial Reconfiguration in Virtex FPGAs,” in Proc. of 2005 International Conference on Field Programmable Logic and Applications, Aug. 24-26, 2005, pp. 211-216.

24. 24 References M. Ullmann, M. Huebner, B. Grimm, and J. Becker, “An FPGA Run-Time System for Dynamical On- Demand Reconfiguration,” in Proc. of the 18th International Parallel and Distributed Processing Symposium, April 26-30, 2004, pp. 135. M. Huebner, C. Schuck, M. Kuhnle, and J. Becker, “New 2-Dimensional Partial Dynamic Reconfiguration Techniques for Real-time Adaptive Microelectronic Circuits,” in Proc. of the 2006 Emerging VLSI Technologies and Architectures, March 2-3, 2006, pp. 6. S. Lopez-Bueno, and I. Gonzalez, “How to Implement Self-Reconfigurable Coprocessors on Spartan- 3,” presentation, Universidad Autonoma de Madrid. R. Hymel, A. George, and H. Lam, “Evaluating Partial Reconfiguration for Embedded FPGA Applications,” Proc. of 11th Annual High Performance Embedded Computing Workshop, Lexington, MA, September 19-21, 2007. S. Wichman, S. Adyha, S. Ahrens, R. Ambli, B. Alcorn, D. Connors, and D. Fay, “Partial Reconfiguration Across FPGAs,” Proc. of Military and Aerospace Applications of Programmable Logic Devices and Technologies Conference, September 26-28, 2006. W. Zheng, N. Marzwell, and S. Chau, “In-System Partial Run-Time Reconfiguration for Fault Recovery Applications on Spacecrafts,” Proc. of IEEE International Conference on Systems, Man, and Cybernetics, Vol. 4, October 10-12, 2005, pp. 3952-3957. V. Eck, P. Kalra, R. LeBlanc, and J. McManus, “In-Circuit Partial Reconfiguration of RocketIO Attributes,” E. Shiflet and L. Hansen, “FPGA Partial Reconfiguration Mitigates Variability,” EE Times Online article, April 4, 2006.