| Dynamic partial reconfiguration on FPGA |
|
|
Save this page
|
Page 4 of 5 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. |