Since 80’s the FPGA market growing rapidly with varied of applications in different industries. FPGA manufactures keep updating their FPGAs with cutting edge technologies. In the recent days there is new concept evolving in FPGA industry so called Dynamic partial reconfiguration.
The new breed of existing FPGA enabled for this feature.This makes the FPGA to be used in a new dimension with an advantage of more flexibility
The new breed of existing FPGA enabled for this feature.This makes the FPGA to be used in a new dimension with an advantage of more flexibility
1.1. What is dynamic partial reconfiguration?
Dynamic Partial Reconfiguration provides a way to modify the implemented logic in FPGA when the device is on.More clearly DPR allows reconfiguring selected areas of a FPGA when other parts of FPGA still working. DPR is not supported on all FPGAs. For example in Xilinx Spartan 3, Virtex II, Virtex II Pro, and Virtex 4 are only supported.
In this chapter we are going to discuss more detail about Dynamic Partial Reconfiguration and it is terminology. The DPR discussion on this chapter is based on Virtex Pro II. Although it is little difficult to implement DPR there are many prominent advantages in it. Let’s discuss the terms which are used in DPR design flow
pictorial view - dynamic partial reconfiguration
The dynamic parts (dynamic modules, dmodules, d_modules, etc.) are independent parts of the input design that need not be active during the whole application runtime. They share common areas (slots) inside a target device; this is based on the assumption that they are not required to run at the same time in parallel.
They are loaded to and unloaded from a target device as requested by the system scheduler. Usually they reside as a bit stream in a memory outside the FPGA. There some cases they also can be stored in the memory available inside the FPGA.
2.2. Static Part
The static part is such a part of an input design that is active during the whole application runtime. It is placed in the “static” area of a target device that is kept intact all the time.
In addition to its standard function it has to provide an infrastructure to load and unload other (dynamic) parts of the design, which is system scheduling, data management, and interface management.
The static part must include the configuration controller and logic required for data and interface management. All inputs/outputs of the application are managed by the static part that communicates with dynamic modules through a fixed interface.
The static part is such a part of an input design that is active during the whole application runtime. It is placed in the “static” area of a target device that is kept intact all the time.
In addition to its standard function it has to provide an infrastructure to load and unload other (dynamic) parts of the design, which is system scheduling, data management, and interface management.
The static part must include the configuration controller and logic required for data and interface management. All inputs/outputs of the application are managed by the static part that communicates with dynamic modules through a fixed interface.
2.3 Bus Macros
Bus macros are used as fixed data paths for signals going between a reconfigurable module and another module. The HDL code should ensure that any reconfigurable module signal that is used to communicate with another module does so only by first passing through a bus macro.
There are Virtex, Virtex-E, Virtex-II, and Virtex-II Pro series specific versions of the bus macro. Be sure to instantiate the version compatible to the chosen device. Each bus macro provides for 4 bits of intermodule communication. As many bus macros as needed must be instantiated to match the number of bits traversing the boundaries of the reconfigurable modules.
As an example, if reconfigurable module A communicates via 32 bits to module B, then eight (32/4) bus macros will need to be instantiated to define the data paths between modules A and B. The details of bus macro usage are described in the Bus Macro Communication section.
Dataflow in bus macro is always unidirectional. So Bus macros configured for Data flow in only one direction and it is fixed. Xilinx Provides these Bus Macros. Also it is possible to design our won bus macros.
2.4 Configuration controller
Configuration controller is part of the static module. This takes care of loading and unloading of dynamic modules. Usually this configuration controller is a microcontroller. In the following diagram gives an idea of position of configuration controller.
Configuration controller makes the design autonomous. That means reconfiguration does not need any manual control. All we have to tell the microcontroller that when it has to configure and which module it has to configure. This can be done using ‘C’ program or assembly program depending on the designer conveniences.
In case of Virtex Pro II it has got two kinds of microcontroller as we seen in the previous chapter. These controllers can be configured as a configuration controller with help of Xilinx EDK tool.
2.5 Configuration of FPGA
There are certain constrains are applied while configuring the FPGA. The reconfigurable module height is always the full height of the device and it should occupy minimum of 4 slices or multiplies of 4 (4, 8, 12, 16…..and so on). As we seen before all stuffs what we are disussing here is applicable only to Virtex Pro II device. Configuration on Virtex Pro II is explained in the following diagram.
Bus macros are used as fixed data paths for signals going between a reconfigurable module and another module. The HDL code should ensure that any reconfigurable module signal that is used to communicate with another module does so only by first passing through a bus macro.
Placement of bus macro
There are Virtex, Virtex-E, Virtex-II, and Virtex-II Pro series specific versions of the bus macro. Be sure to instantiate the version compatible to the chosen device. Each bus macro provides for 4 bits of intermodule communication. As many bus macros as needed must be instantiated to match the number of bits traversing the boundaries of the reconfigurable modules.
Boundry between modules
As an example, if reconfigurable module A communicates via 32 bits to module B, then eight (32/4) bus macros will need to be instantiated to define the data paths between modules A and B. The details of bus macro usage are described in the Bus Macro Communication section.
Placement of bus macro FPGA editor
Dataflow in bus macro is always unidirectional. So Bus macros configured for Data flow in only one direction and it is fixed. Xilinx Provides these Bus Macros. Also it is possible to design our won bus macros.
2.4 Configuration controller
Configuration controller is part of the static module. This takes care of loading and unloading of dynamic modules. Usually this configuration controller is a microcontroller. In the following diagram gives an idea of position of configuration controller.
Configuration controller makes the design autonomous. That means reconfiguration does not need any manual control. All we have to tell the microcontroller that when it has to configure and which module it has to configure. This can be done using ‘C’ program or assembly program depending on the designer conveniences.
In case of Virtex Pro II it has got two kinds of microcontroller as we seen in the previous chapter. These controllers can be configured as a configuration controller with help of Xilinx EDK tool.
DPR Enabled FPGA
2.5 Configuration of FPGA
There are certain constrains are applied while configuring the FPGA. The reconfigurable module height is always the full height of the device and it should occupy minimum of 4 slices or multiplies of 4 (4, 8, 12, 16…..and so on). As we seen before all stuffs what we are disussing here is applicable only to Virtex Pro II device. Configuration on Virtex Pro II is explained in the following diagram.
Configuration on FPGA
3. Advantages
There are many benefits that come with DPR
3.1 Applications
Partial reconfiguration is useful in a variety of applications across many industries. The aerospace and defense industries have certainly taken advantage of its capabilities. Partially reconfigurable devices have benefited the Joint Tactical Radio System (JTRS) Program, which I’ll discuss more in the following section.
3.2 Increased system performance
Although a portion of the design is being reconfigured, the rest of the system can continue to operate. There is no loss of performance or functionality with unaffected portions of a design – no down time. It also allows for multiple applications on a single FPGA.
3.3 The ability to change hardware
Xilinx FPGAs can be updated at any time, locally or remotely. Partial reconfiguration allows you to easily support, service, and update hardware in the field.
3.4 Hardware sharing
Because partial reconfiguration allows you to run multiple applications on a single FPGA, hardware sharing is realized. Benefits include reduced device count, reduced power consumption, smaller boards, and overall lower costs.
3.5 Shorter reconfiguration times
Configuration time is directly proportional to the size of the configuration bitstream. Partial reconfiguration allows you to make small modifications without having to reconfigure the entire device. By changing only portions of the bitstream – as opposed to reconfiguring the entire device – the total reconfiguration time is shorter.
3.1 Limitations and Challenges
Different FPGA devices provide different capabilities. To benefit from the maximum functional density while keeping sufficient performance the designer should select the most convenient technology for a specific application (for example, the Xilinx Virtex / Virtex-II / Virtex-E devices can be reconfigured only whole columns at once).
It is also recommended to check the back-end tools for some other possible limitations. For example, the Xilinx back-end tool cannot analyze the dependencies between dynamic modules. The designer must do this analysis by himself. Other example may be the Atmel back-end tool. It can generate design configurations, but unfortunately the dynamic modules must be loaded / unloaded in the same sequence as it were implemented. All these limitations are not related to the technology and they will be probably solved in future tool versions. Unfortunately the designer must count on it and modify the design strategy to minimize the design effort.
The next very important perspective is the application performance. The dynamic reconfiguration increases the functional density, but it is achieved with the cost of a decrease in the application performance. The designer must optimise these two parameters to satisfy the technical requirement specification (TRS).
The designer should always analyse the application in detail and try to estimate the resulting performance. The performance must satisfy the TRS and in addition it must overcome other implementation technologies (DSP, uControllers, etc.) at least in another important parameter (power dissipation, size, weight, cost, design time, etc.). If not, the designer should probably select the other technology.
There are many benefits that come with DPR
3.1 Applications
Partial reconfiguration is useful in a variety of applications across many industries. The aerospace and defense industries have certainly taken advantage of its capabilities. Partially reconfigurable devices have benefited the Joint Tactical Radio System (JTRS) Program, which I’ll discuss more in the following section.
3.2 Increased system performance
Although a portion of the design is being reconfigured, the rest of the system can continue to operate. There is no loss of performance or functionality with unaffected portions of a design – no down time. It also allows for multiple applications on a single FPGA.
3.3 The ability to change hardware
Xilinx FPGAs can be updated at any time, locally or remotely. Partial reconfiguration allows you to easily support, service, and update hardware in the field.
3.4 Hardware sharing
Because partial reconfiguration allows you to run multiple applications on a single FPGA, hardware sharing is realized. Benefits include reduced device count, reduced power consumption, smaller boards, and overall lower costs.
3.5 Shorter reconfiguration times
Configuration time is directly proportional to the size of the configuration bitstream. Partial reconfiguration allows you to make small modifications without having to reconfigure the entire device. By changing only portions of the bitstream – as opposed to reconfiguring the entire device – the total reconfiguration time is shorter.
3.1 Limitations and Challenges
Different FPGA devices provide different capabilities. To benefit from the maximum functional density while keeping sufficient performance the designer should select the most convenient technology for a specific application (for example, the Xilinx Virtex / Virtex-II / Virtex-E devices can be reconfigured only whole columns at once).
It is also recommended to check the back-end tools for some other possible limitations. For example, the Xilinx back-end tool cannot analyze the dependencies between dynamic modules. The designer must do this analysis by himself. Other example may be the Atmel back-end tool. It can generate design configurations, but unfortunately the dynamic modules must be loaded / unloaded in the same sequence as it were implemented. All these limitations are not related to the technology and they will be probably solved in future tool versions. Unfortunately the designer must count on it and modify the design strategy to minimize the design effort.
The next very important perspective is the application performance. The dynamic reconfiguration increases the functional density, but it is achieved with the cost of a decrease in the application performance. The designer must optimise these two parameters to satisfy the technical requirement specification (TRS).
The designer should always analyse the application in detail and try to estimate the resulting performance. The performance must satisfy the TRS and in addition it must overcome other implementation technologies (DSP, uControllers, etc.) at least in another important parameter (power dissipation, size, weight, cost, design time, etc.). If not, the designer should probably select the other technology.
3.3 Verification of DPR enabled FPGA
Verification is another important issue in the DPR. Since all modules of the design does not present at any particular time make the verification difficult. The following flow is adopted for verification dynamic behavior.
In the diagram The FCC (Functional configuration controller) is the software equivalent of hardware configuration controller. While doing verification the FCC is switching the dynamic module. Designing of FCC is an additional work for the verification engineers.
A. References
1.Benefits of Partial Reconfiguration
- Cindy Kao, Marketing Specialist, Xilinx, Inc
2.Managing Partial Dynamic Reconfiguration in Virtex-II Pro FPGAs
- Philippe Butel, Gerard Habay, Alain Rachet
3.Virtex-II Pro and Virtex-II Pro X FPGA User Guide
- Xilinx, Inc
4.Virtex-II Pro and Virtex-II Pro X Platform FPGAs
- Complete Data Sheet – Xilinx, Inc
5.Virtex Series configuration architecture user guide
- Application Note – Xilinx, Inc
9.Modular Partial Reconfiguration in Virtex FPGAs
- Pete Sedcole, Brandon Blodget, James Anderson, Patrick Lysaght and Tobias Becker
7. RECONF – Design Guidelines
- Martin Daněk,Manuel Moreno,Kelly Nasi,Stefano Baldacci, Gerard Habay,Alain Rachet
Verification is another important issue in the DPR. Since all modules of the design does not present at any particular time make the verification difficult. The following flow is adopted for verification dynamic behavior.
DPR verification flow
A. References
1.Benefits of Partial Reconfiguration
- Cindy Kao, Marketing Specialist, Xilinx, Inc
2.Managing Partial Dynamic Reconfiguration in Virtex-II Pro FPGAs
- Philippe Butel, Gerard Habay, Alain Rachet
3.Virtex-II Pro and Virtex-II Pro X FPGA User Guide
- Xilinx, Inc
4.Virtex-II Pro and Virtex-II Pro X Platform FPGAs
- Complete Data Sheet – Xilinx, Inc
5.Virtex Series configuration architecture user guide
- Application Note – Xilinx, Inc
9.Modular Partial Reconfiguration in Virtex FPGAs
- Pete Sedcole, Brandon Blodget, James Anderson, Patrick Lysaght and Tobias Becker
7. RECONF – Design Guidelines
- Martin Daněk,Manuel Moreno,Kelly Nasi,Stefano Baldacci, Gerard Habay,Alain Rachet
No comments:
Post a Comment