partial reconfiguration protocol on Spartan II and self reconfiguration

  • Follow



Hello folk,

I've been supervising a project on reconfigurable computing at my
University whose objective is to create a prototype of a
self-reconfigurable FPGA.

The board is a small Xess XSA-100 mounting a Spartan-II 100 FPGA.
The steps of the project should have been the following:

1) Use two distinct boards, with a "master" board dowloading a
bitstream to a "slave" board.
2) Create a partial reconfiguration project (the "classical" Xilinx
xapp290) on a single board.
3) Create a partial reconfiguration project, with the fixed portion of
the design reconfiguring the FPGA itself, the same way as step 1) but
using a single FPGA as both the master and the slave.

Well, the first two steps succeeded. The third, unfortunately, didn't.

The guy who was working on the project stopped the work as his
internship period expired. Anyway, he gave me an almost-finished
project which -he says- only need some debugging.
He used a SelectMap parallel configuration mode for all the above
experiments.
Of course, step 1) required a full reconfiguration, while step 3)
required partial reconfiguration. He said that, probably, the
electrical protocol for partial reconfiguration is different from that
for full reconfiguration.

In fact, he said that for partial reconfiguration one shouldn't assert
the "/PROGRAM" signal, nor wait for a "/INIT" signal from the FPGA. It
should be sufficient to assert the "/CS" and "/RDWR" signals to
initiate a partial bitstream download to the FPGA, while asserting the
"/PROGRAM" signal would erase the full FPGA configuration (and thus the
block that manages the reconfiguration from the FPGA itself). I'm not
sure about that.

Are you aware of a different protocol that is required when using
SelectMap mode for partial reconfiguration instead of full
reconfiguration? In particular, do you think that asserting the
"/PROGRAM" signal really erases the full FPGA configuration being thus
incompatible with partial reconfiguration??

Currently, we only assert the signals "/CS" and "/RDWR", and then,
after a couple of garbage bytes, we put "FFFFFFFFAA995566" followed by
the rest of the partial bitstream on the FPGA data port. After
downloading the bitstream and deasserting "/CS" and "/RDWR" nothing
changes, the initial bitstream is still there and -strangely enough- it
is (almost always) reset and restarted.

Do you have any suggestions (including any hints on bitgen flags) ???
Many, many thanks !!

ale


PS. When the project will work, all material will be made publicly
available.

0
Reply sec_lab (2) 6/3/2006 6:12:14 PM


0 Replies
82 Views

(page loaded in 0.019 seconds)


Reply: