Page 1 of 1
Ongoing trends in logic design such as shorter product lifecycles, greater design complexity and increased scaling (e.g., “Moore’s Law”) are adding increasing pressure for faster design speed and lower power in a smaller physical space. Although today’s advanced FPGAs are rapidly evolving to address these issues of speed, power and size, new technologies in the area of partial reconfiguration offer the promise of even greater advances.
Partial reconfiguration is a design process that 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 and cannot be disrupted while subsystems are redefined. The ability to partially reconfigure a device takes the already powerful benefits of reprogrammability to a much higher level.
The obvious benefit of reconfigurable devices, such as FPGAs, is that the functionality with which a device is configured can be changed and updated at some time in the future. As additional functionality is available or design improvements are made available, the FPGA can be shut down, completely reprogrammed with new logic and operations can be resumed. Partial reconfigurability addresses the environment where logic needs to be changed or updated within a part of an FPGA without disrupting the entire system. This may be a design comprised of several blocks of logic and, without disrupting the system and stopping the flow of data, requires an update of the functionality within one block.
Using partial reconfiguration, designers can dramatically increase the functionality of a single FPGA, allowing for fewer, smaller devices than would otherwise be needed. This allows for additional functionality, lower power, reduced cost and less physical space on the board.
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 allows concurrent support for multiple independent applications in a single FPGA. This is somewhat analogous to dynamic task switching or multitasking of a general-purpose processor. Without this capability, it would be necessary to reconfigure the entire FPGA to support a different application, which would result in the loss of all previous applications.
Partial reconfiguration provides an advantage over multiple full bit streams in applications that require continuous operation, which is not otherwise accessible 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 may 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.
In order to implement partial reconfiguration on an FPGA, it first requires an FPGA that inherently supports the dynamic reconfiguration of only portions of the device, while leaving the other portions unaffected. Then a set of software development tools are needed that support the development of applications restricted to boundaries that comply with the hardware architecture of the FPGA. Finally, some form of basic controller must be available to dynamically manage the reconfiguration of the FPGA. This could be an embedded general-purpose processor (GPP), a soft core GPP, or an external GPP connected to the FPGA. In this shared resources model, the same embedded GPP that is running the design infrastructure and operating environment is also managing the partial reconfiguration of the FPGAs.
In an 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 define the look-up table (LUT) equations, signal routing, input/output block (IOB) voltage standards and all other aspects of the design.
To program 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.
Typically, a user performs the initial programming by downloading an entire bitstream to an inactive target device. Using partial reconfiguration, a subset of the FPGA can be reprogrammed using a partial bitstream. You can use partial bitstream to change the structure of one part of an FPGA design as the rest of the active device continues to operate.
A Methodology for Partial Reconfiguration
Successful implementation of a design using a partially reconfigurable flow requires following a strict design methodology. A reconfigurable design will consist of partially reconfigurable modules (PRMs) that will be swapped in and out of the FPGA and the static logic, which will remain in place. The general picture of the design flow involves the need to insert bus macros between the PRMs and the rest of the design, the static or fixed logic that remains in place. Bus macros are the channels or ports through which modules communicate and pass data. This allows a fixed communication channel for the static logic regardless of the reconfigurable logic on the other side.
Successful design requires following the guidelines of the synthesis tools to generate a partially reconfigurable net list. The synthesis tool must be configured so that no optimizations occur across hierarchical boundaries. This is generally done with a KEEP_HIERARCHY or similar directive.
The next step is to use the tool to floorplan the PRMs and cluster all static modules together and then place the bus macros between the PRMs and the static logic following PRM-specific design rules. Finally, run the partial reconfiguration implementation flow
PlanAhead 8.1 from Xilinx is an example of a single environment (or platform) used to manage the preceding guidelines, which can be broken down into the following steps:
1. Net list import
2. Floorplanning the design for partial reconfiguration
3. Design rule checks
4. Net list export
5. Implementation flow management
6. Bitstream size estimation
Although these steps are straightforward, the methodology requires meticulous implementation in order to ensure success. Changing out a portion of a complex, high-speed design does not allow much margin for error.
Use a tool like PlanAhead that works with imported net lists, such as those from XST or Synplify, to import any hierarchical net list (single edf/ngc or multiple edf/ngc files). Then follow the regular guidelines to import the design into the tool and create a floorplan as you would with any non-partially reconfigurable design.
Floorplaning for partial reconfiguration is an important step in the partial reconfiguration flow. Floorplanning 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. The designer can define Pblocks without rectangles and the implementation software will attempt to group the logic during placement. Net list logic placed inside of Pblocks will receive AREA_GROUP constraints.
Floorplanning for partial reconfiguration entails several key subtasks. The first subtask is to assign an area for the PRM by creating a Pblock with an area defined within the fabric. This includes assigning the values for RANGES for the Pblock. The MODE constraint must be defined for all reconfigurable regions (MODE=RECONFIG). This constraint prevents the implementation tools from failing with unexpanded block errors during implementation of the static and reconfigurable modules.
Every top-level module, other than 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 PRMs) and assign them to a Pblock. Figure 1 shows the static logic grouped in a Pblock named AG_base. When the floorplanning is completed in the design tools, the resulting physical hierarchy will be organized as shown in Figure 2.
The next step is to place the bus macros. Bus macros are physical ports that connect a PRM to static logic. Any connection from a PRM to static logic should always go through a bus macro. Bus macros are instantiated as black boxes in RTL and are filled with a predefined routing macro in the form of an .nmc file. Bus macros are placed on the PRM boundary. Static logic connected to PRMs will migrate toward the bus macro during placement.
Given the complexity of the flow, it is very common for mistakes to be introduced in the original RTL and during the floorplanning process. Any tool worth its salt will check for design violations. Also integrated into this feature, in the case of PlanAhead is the PR-Advisor, which provides feedback on how to improve your design. There are a number of design rule checks that are specific to Partial Reconfiguration.
The bus macro DRC 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. Figure 3 shows an example of a design that failed the PRBP DRC. In this case, the tool tells us that the interleaved/nested macro should be placed at SLICE_X41Y.
The Floorplanning DRC covers floorplanning rules. Clock objects (global clock buffers, DCM) and I/Os should be placed and static logic clustered. The glitching logic DRC verifies glitching logic elements (SRL and distributed RAM) above and below PRM regions.
Another DRC is the timing advisor/DRC. This provides a check for timing-related issues. One example of timing DRC is the PRTB 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 the example in Figure 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.
Once the design is floorplanned and passes the DRC checker, it is ready to be exported. The design tools should take care of exporting the original hierarchical net list into a PR-style net list that has a specific format (static and PRM in separate directories). The export directory will appear as shown in Figure 5. Next, a partial reconfiguration flow wizard, shown in Figure 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)
The Pblock statistics report includes a section that reports PRM bitstream size (Figure 6). 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.
Partial reconfiguration offers a tremendous opportunity for designers looking for a way to increase the functionality of their design, achieve lower power and reduce the number of devices on their board. Using new design tools and techniques becoming available 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 along with the required power, board space and design overhead. n
San Jose, CA.