Partial Run Time Reconfiguration (RTR) Question

selectmap partial reconfiguration

Hi,

I have an application that I can implement on a Virtex device by
Partial Run Time Reconfiguration (RTR).

I have a fixed logic Block. And one reconfigurable Logic Block.
Fixed Logic Block is a processing engine (PE). The data for that will be available in the Reconfigurable Logic. I can either use the LUTs as distributed RAM or just use BlockRAM to store my data. My PE will work on the data and when it is finished I will read the output from the PE.
And then, I will load the Reconfigurable block with the new data to be worked on. So all I have to do is change the contents of the LUT/BlockRAM using JBITS and partially reconfigure the Device for the new data to be worked on by the PE. And this is all the device does -- load the Data into the Reconfigurable Logic Block and let the PE(Fixed Logic Block) do the math on it, and this goes on ....

My goal is to eventually make this a scalable appication with a Big Virtex Device with multiple PEs all working on the Data which will be reconfigured using RTR. And finally, develop a platform to have this done over a huge array of FPGAs.

Does anyone know of any work done on this? I would appreciate your comments and suggestions.

1) Can a Virtex device handle this sort of Partial RTR ? Is there a thumb rule regarding how often partial RTR can be done and if this can be done for the life of the device? ( I apologize if this sounds ignorant, I just want to make sure before I spend more time and resources )

TIA
Kode

srl16 run-time reconfig

As much as I know there are several conference papers (presented at FPL, FCCM, FPGA, etc.) discussing how to implement an RTR system/application using Virtex devices and JBits. Recently, Xilinx also has published an application note describing how to make a runtime reconfigurable configuration of FPGA devices using the ISE 5.1 or higher.

Regarding your idea mentioned, I think there are some issues to be addressed: how fast can you reconfigure the device(s)? what about the configuration bandwidth and interface (e.g. SelectMap)? How do you provide/store multiple configuration data or generate them on-the-fly (using host compupter, embedded processor, ...)? What kind of applications are targeted?

store configuration

Thanks for your reply. I needed those questions to think for myself.


how fast can you reconfigure the device(s)?How do you provide/store multiple configuration data or generate them on-the-fly (using host compupter, embedded processor, ...)?

-- I will be using JBITS API to modify the bitstream. so this will be generated on the fly by the host computer. The only modification to the bitstream is it has to replace certain LUTs which are connfigured as RAM with the new data.
Yes this will be generated on the fly. The challenge is to make sure that my Processing Engines (PEs) on the Fixed Logic Block are always being used. And somehow cache/pipeline my reconfiguration data on to the FPGA so its never waiting for the data on the Reconfigurable Block.

Lets say the Tc = Computation Time for the PE
and Trc = Time to reconfigure the device and have the new data available just in time/early in the Reconfigurable Block so my PE is not wasting anytime. And my bet is ( I am still working on the design ) that the Tc will be a little smaller than that of the Trc. I would know this once I have my design and my tools done. Then I will have to have an optimal algorithm in terms of scheduling Reconfiguration.

what about the configuration bandwidth and interface (e.g. SelectMap)?
--I will be doing the confgiuration via XHWIF which ispart of JBits API . Does this answer your question?

What kind of applications are targeted?
Bioinformatics. specifically sequence matching. Unfortunately, I dont have lot of big boards to use at my disposal. I have XCV300 board from Xess to work with right now. Once I get this working on this board, I will move on to bigger boards..hopefully Xilinx will be willing to donate some boards to a poor graduate Student

run-time reconfiguration srl

I think using JBits to readback, modify and reconfigure
the device requires a large amount of processing time.
Partial reconfiguration might be used (I think this feature
is also supported by Jbits). But due to the architecture
constraints you can reconfigure only a whole CLB columns
of a Virtex device. Techniques like reconfiguration pipelining
or configuration/execution interleaving techniques may help
further reduce the configuration overhead.

However, if you want to change only the contents of the LUTs
(no run-time rerouting and module replacement), then I would
suggest you to use another method. You can implement your logic
functions (e.g. decoders, pattern matchers) using SRL elements
instead of LUT elements. You can connect the SRL elements to
build a serial chain. Multiple chains can exist in your design.
Now, you need a small controller (e.g. Picoblaze) or a simple FSM
that controls the reconfiguration process and provides new
configuration data to the SRL by shifting the configuration bits
through the chain for update. After that you can use the SRL
elements as normal LUTs for your computation. Each SRL element
requires 16 bits, that means, you need #SRL*16 cycles to shift the
configuration bits, where #SRL is the number of SRL elements
in the chain. If you use the Virtex II family (instead of Virtex
and Virtex-E), each SRL element of this family has a serial input
and output which allow you to easily build a chain of SRL elements.
It is also possible to use a soft-IP processor to calculate and provide
new configuration data to the reconfiguration controller.
The communication between the circuits inside the device and
the host PC should be kept minimum.

Whether this method is applicable to your application or not, it
depends strongly upon the characteristics of your application.
I hope my suggestion might be useful for your work...