Partial reconfiguration is a design process, which allows a limited, predefined portion of an FPGA to be reconfigured while the remainder of the device continues to operate. This is especially valuable where devices operate in a mission-critical environment that cannot be disrupted while some subsystems are being redefined.
Using partial reconfiguration, you can dramatically increase the functionality of a single FPGA, allowing for fewer, smaller devices than would otherwise be needed. Important applications for this technology include reconfigurable communication and cryptographic systems.
In an SRAM-based FPGA, all user-programmable features are controlled by memory cells that are volatile and must be configured on power-up. These memory cells are known as the configuration memory, and they define the look-up table (LUT) equations, signal routing, input/output block (IOB) voltage standards, and all other aspects of the design.
In order to program the configuration memory, instructions for the configuration control logic and data for the configuration memory are provided in the form of a bitstream, which is delivered to the device through the JTAG, SelectMAP, serial, or ICAP configuration interface.
An FPGA can be partially reconfigured using a partial bitstream. You can use such a partial bitstream to change the structure of one part of an FPGA design as the rest of the device continues to operate.
Use cases for partial Reconfiguration
Partial reconfiguration is useful for systems with multiple functions that can time-share the same FPGA device resources. In such systems, one section of the FPGA continues to operate, while other sections of the FPGA are disabled and reconfigured to provide new functionality. This is analogous to the situation where a microprocessor manages context switching between software processes. In the case of partial reconfiguration of an FPGA, however, it is the hardware – not the software – that is being switched.
Partial reconfiguration provides an advantage over multiple full bitstreams in applications that require continuous operation, which would not be possible during full reconfiguration. One example is a graphics display that utilizes horizontal and vertical synchronization. Because of the environment in which this application operates, signals from radio and video links need to be preserved – but the format and data processing format require updates and changes during operation. With partial reconfiguration, the system can maintain these real-time links while other modules within the FPGA are changed on the fly.
A Methodology for Partial Reconfiguration
In order to implement a partial reconfiguration design successfully, you have to follow a strict design methodology. Here are some guidelines to follow:
- Insert bus macros between modules that need to be swapped out (called partial reconfiguration modules, or PRMs) and the rest of the design (static logic). These are the channels, or ports, through which modules communicate and pass data.
- Follow synthesis guidelines to generate a partially reconfigurable netlist.
- Floorplan the PRMs and cluster all static modules.
- Place bus macros.
- Follow PR-specific design rules.
- Run the partial reconfiguration implementation flow.
- Netlist import.
- Floorplanning the design for partial reconfiguration.
- Design rule checks.
- Netlist export.
- Implementation flow management.
- Bitstream size estimation.
Netlist import
PlanAhead 8.1 works with any synthesized netlist, such as XST or Synplify. You can import any hierarchical netlist (single edf/ngc or multiple edf/ngc files). Follow the regular guidelines to import the design into the PlanAhead design tools and create a floorplan as you would with any non-partially reconfigurable design.
Floorplanning for partial reconfiguration
This is an important step in the partial reconfiguration flow. Floorplanning within PlanAhead software is based on design partitions referred to as physical blocks, or Pblocks. A Pblock can have an area (such as a rectangle) defined on the FPGA device to constrain the logic. You can define Pblocks without rectangles and ISE software will attempt to group the logic during placement. Netlist logic placed inside of Pblocks will receive AREA_GROUP constraints.
The key floorplanning sub-tasks for partial reconfiguration are as follows:
- Setting up a PRM:
- Assign an area for the PRM by creating a Pblock with an area defined within the fabric.
- Assign RANGES for the Pblock.
- Define the MODE=RECONFIG attribute on the PRM
(Pblock property->attribute section)
- Setting up static logic:
- Every top-level module, other then PRMs, should be grouped together in a single Pblock. This is called a static logic block. This block should not have a RANGE defined; this will cluster the static logic together in a single Pblock. Select all top-level modules (except the PRM) and assign it to a Pblock. The static logic grouped in a Pblock named AG_base is shown in Fig 1.
- When you have completed the floorplanning in PlanAhead design tools, the resulting physical hierarchy will be organized as shown in Fig 2.
- Bus macro placement:
1. All static logic is grouped in a single Pblock AG_base.
2. The hierarchy for a partial reconfiguration design.
Given the complexity of the flow, it is common for mistakes to be introduced in the original RTL and during the floorplanning process. PlanAhead-PR design tools check for design violations. Also integrated into this feature is the PR-Advisor, which provides feedback on how to improve your design.
The PR design rule checks are as follows:
- Bus macro DRC: This provides verification for all design rules related to bus macro connectivity and placement. One example of a bus macro DRC is the PRBP check. This DRC checks for all rules that should be followed for bus macro placement. An example of a design that failed the PRBP DRC is shown in Fig 3. In this case, the interleaved/nested macro should be placed at SLICE_X41Y*.
- Floorplanning DRC: This covers floorplanning rules. Clock objects (global clock buffers, DCM) and I/Os should be placed and static logic clustered.
- Glitching logic DRC: This verifies glitching logic elements (SRL and distributed RAM) above and below PRM regions.
- Timing advisor/DRC: This provides a check for timing-related issues. One example of timing DRC is the PRTP check. With the PRTB check, the static module is implemented before the PRM during the implementation phase. Regular timing constraints do not cover the paths that cross between the static and a PRM module. This does not present a problem, provided that the bus macro is synchronous. However, if it is an asynchronous bus macro, the static module does not know about the propagating of asynchronous paths, as shown in Fig 4. This could be important if these paths are timing-critical. One way to pass this information to the static module is to specify a TPSYNC constraint on the bus macro output net. PlanAhead software will recommend a TPSYNC constraint that can be added to the .UCF file.
3. The PRBP DRC verifies all rules that should be
followed for bus macro placement.
4. Special consideration should be given to timing-critical paths,
which include an asynchronous path.
Once the design is floorplanned and passes the DRC checker, it is ready to be exported. PlanAhead design tools take care of exporting the original hierarchical netlist into a PR-style netlist that has a specific format (static and PRM in separate directories). The export directory will appear as shown in Fig 5.
5. Upon successful completion of the floorplanning DRC processes, all modules will be displayed in black text within the Export Floorplan dialog box.
The partial reconfiguration flow wizard (shown in Fig 6), runs the partial reconfiguration implementation on the exported design. It will produce a full bitstream for the complete design and a partial bitstream for each of the PRMs. The implementation steps are:
- Initial budgeting.
- Static module implementation.
- PRM module implementation (one implementation for each version of every PRM).
- Assembly and bitstream generation (results are stored in the merge directory).
6. The PlanAhead partial reconfiguration flow wizard
provides an easy-to-follow flow.
Bitstream size estimation
The Pblock statistics report includes a section that reports PRM bitstream size (Fig 7). This information can be used for estimating the size of configuration memory storage such as external flash and DDR. This information can also be used to calculate how long it will take to swap the module based on your bitstream memory interface.
7. The display of Pblock properties includes the estimated size of the bitstream.
PlanAhead software is the first graphical environment for partial reconfiguration. Using PlanAhead design tools as a platform for partial reconfiguration applications can greatly simplify the complexities of juggling the dynamic operating environment of these cutting-edge applications, allowing a single device to operate in applications that previously required multiple FPGAs.
The methodology offered by PlanAhead software can dramatically increase productivity and decrease time-to-solution for designers using partial reconfiguration.
The capability of designs to leverage partial reconfiguration opens doors to a whole host of applications. By providing a platform that leverages the advantages of partial reconfiguration, PlanAhead design tools allow you to dramatically extend the functionality of your design. With new support in PlanAhead 8.1 for designs targeting the Virtex-4 multi-platform FPGA, the application space for partial reconfiguration is practically limitless.
Mark Goosman, is a Product Marketing Manager at Xilinx, Inc., Nij Dorairaj is a Senior Staff Engineer at Xilinx, Inc., and Eric Shiflet is a Technical Marketing Engineer at Xilinx, Inc. Mark, Nij, and Eric can be reached at mark.goosman@xilinx.com, nij.dorairaj@xilinx.com, and eric.shiflet@xilinx.com, respectively.
No comments:
Post a Comment