POST_CRC in Spartan-6

Hi all! Anyone tried using the post-configuration scrubbing function in Spartan-6? I am a little at a loss reading the documentation, so any first-hand experience would be valuable. From the configuration user guide (UG380) I have deduced the following limitations:

- INIT_B can not be used as a dual-purpose I/O, even if you set POST_CRC_INIT_FLAG = Disable (UG 380 p 131: "Whether or not the INIT_B pin is used as the error signal, it cannot be used as user I/O when POST_CRC is enabled"). It seems rather silly to even have this option if it does not free up the INIT_B-pin, and from AR#39582

formatting link

it seems this is a bug that will be documented as a feature. Of course you would have to have some other means of conveying any error to the outside world, it just so happens that in our system this would have been easier to do on a different pin that INIT_B.

- What if you use the memory controller? UG380 p 130 says: "Use of the PLL DRP is not masked; therefore, any change to the PLL results in a CRC error". The memory controller is bound to fiddle with the PLL- settings and I assume that is done through the DRP, does that imply that that POST_CRC can not be used if you have an MCB in the system?

- The same question is valid for the I/O-block DRPs. UG380 p 130 says: "The I/O interface DRP at the top and bottom can be masked". From that one would guess that the left and right banks IO interface DRP can not be masked, so any tuning of the IOB delays in these would render the CRC invalid, right? It doesn't say how the masking is done either...

Any comments? /Lars

P.S. Remove the obvious from my address if you want to email me directly. D.S.

Hi again! No one out there who have given it a try? I have now gotten as far as instantiating the post_crc_internal and hooking it up to an external pin, as well as a ChipScope ILA. They where not kidding about the INIT_B-pin, I could P&R with it used as an I/O, but BitGen threw an error unless I left it unconnected. I didn't have to use the "-g persist" switch though, so all of the other dual-purpose configuration pins could still be used as I/O.

It didn't seem to work as good in practice though, Impact immediately gave a warning saying "CRC error bit is NOT 0", and ChipScope shows the crcerror output high from post_crc_internal, so I still have no idea if this has any potential to work. Good thing is the application seems to work though (minus the pin that doubles for INIT_B). I haven't been able to hook up an oscilloscope to measure the crcerror output in respect to e.g .DONE, maybe I can get around to that later. That might give some insight. I guess I will have to pester my XILINX FAE some more, maybe the I/O DRP and/or MCB PLL d.o. are killers.

Cheers! /Lars