POST_CRC in Spartan-6

[Lars]

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 (http://
www.xilinx.com/support/answers/39582.htm), 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.

 

[Lars]

On 5 Sep, 14:34, Lars <noreply.lar...@gmail.com> wrote:

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 (http://www.xilinx.com/support/answers/39582.htm), 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