Partial Reconfiguration

1
Partial Reconfiguration

• Chris Conger
• PhD Student Research Assistant
• CHREC Center, University of Florida
• 11/21/2007

2
Outline

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

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
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
Introduction

• So whats the problem? Why has PR not taken off?
• Merciless design flow application designers and
  scientists already dont like VHDL/Verilog, PR
  design is even more low-level

6
Introduction

• So whats the problem? Why has PR not taken off?
• Merciless design flow application designers and
  scientists already dont like VHDL/Verilog, PR
  design is even more low-level
• Requires special patch to Xilinxs design
  software (ISE), not yet publicly released

7
Introduction

• So whats the problem? Why has PR not taken off?
• Merciless design flow application designers and
  scientists already dont like VHDL/Verilog, PR
  design is even more low-level
• Requires special patch to Xilinxs 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
Introduction

• So whats the problem? Why has PR not taken off?
• Merciless design flow application designers and
  scientists already dont like VHDL/Verilog, PR
  design is even more low-level
• Requires special patch to Xilinxs 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
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 2000s
• 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
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 DONT 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
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
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 Xilinxs modular design flow
• Must use special patched version of ISE for
  implementation flow (any synthesis tool is fine)

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
PR Design vs. Regular Design

• Synthesis, implementation flow differences
• Top-level HDL file and each main module are
  synthesized separately

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
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
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
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
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 design
Multi-purpose system design
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
Example Use-Cases of PR

• Fault tolerant architecture
• Configuration scrubbing, self-reconfiguration
• BIST for permanent faults

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
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
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.