Transcript F1 for CKW

Partial Reconfiguration
Event title here
Chris Conger
PhD Student & Research Assistant
CHREC Center, University of Florida
11/21/2007
11/21/2007
Outline

Introduction

History of Partial
Reconfiguration

PR Design vs.
Regular Design

Performance Impact

CHREC Research

References
2
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
3
Introduction

What are the benefits of PR?

Critical modules may remain un-interrupted during reconfiguration of a
different part of design



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



Network connections do not need to be broken and re-initialized
XD1000 platform is perfect example of needing this capability
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)
4
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
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
Requires special patch to Xilinx’s design software (ISE), not yet publicly
released
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
Despite apparent benefits, difficult to identify applications or systems which
stand to benefit from the capabilities offered through PR
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

Necessity was not the mother of this invention!
8
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
9
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:



U.S. military and defense contractors see SDR as critical technology for
future of warfare


Time-multiplexing of a device
Un-interrupted operation of static portion of design
Dept. of Defense has deep pockets = motivation for Xilinx
Xilinx finally engineered a workable design flow for PR within their standard
ISE development environment
10
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
11
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)
12
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 toplevel HDL file
Module HDL files (all but top-level) CANNOT include:



Input/Output buffers
Clocking primitives
Bus macros
13
PR Design vs. “Regular” Design

Synthesis, implementation flow differences

Top-level HDL file and each main module are
synthesized separately
14
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
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




“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
16
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
17
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
18
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
19
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
20
Example Use-Cases of PR

Fault tolerant architecture


Configuration scrubbing, self-reconfiguration
BIST for permanent faults
21
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 nonhardware designers
If you are interested in PR research, contact
myself, Dr. George, Dr. Gordon-Ross, or Dr. Lam
22
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.
23
References

M. Ullmann, M. Huebner, B. Grimm, and J. Becker, “An FPGA Run-Time System for Dynamical OnDemand 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 Spartan3,” 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.
24