02-04-2018 08:28 AM - edited 02-04-2018 11:54 AM
I'm facing a very odd problem (kind of a very interesting thing)...
I use a XCVU065 on a custom PCA. Vivado 2016.3.
The PCA features a SPI-flash used for FPGA configuration.
The configuration mode is SPIx1 with 3MHz - so quit slow.
Configuration of the FPGA - either after power up or triggered by progam_b - works fine. Init_B and done are both high after configuration.
BUT: fcs_b stays low! Meaning the spi is still active.
AND cclk is still running.
The very odd thing is that after around 60s the FPGA sends "something" on MOSI. Because fcs_b is still low, the flash answers.
And this happens periodically with a period of ~ 60s.
So far so good - the problem is - the configuration memory changes !!! (Verified by readback of configuration memory via JTAG!)
This led to very strange behavior of the FPGA like init_b suddenly going low after 10-20 minutes and GTY-QPLL loosing lock.
Now the question is: why does fcs_b stays low? It should go high after configuration is finished and done goes high.
And why is the FPGA sending "something" after configuration has finished?
02-04-2018 09:06 PM
Firstly the query should have been posted in configuration Community.
To your query looks to me to be a case of incorrect BITSTREAM settings, can you check if you have PERSIST (BITSTREAM.CONFIG. PERSIST) settings enabled in your bit stream unintentionally, which is causing the FCS_B not to go high after config.
02-05-2018 02:24 AM
2.4Kohm pull up resistor is recommended for FCS_B for spi interface, can you check if this is followed?
02-05-2018 05:05 AM - edited 02-05-2018 12:07 PM
I intentionally set this setting to seperate configuration IOs and user-IOs staying on the safe side regarding configuration.
I cannot find any documentation saying that fcs_b is held low and the FPGA periodically requests something on MOSI in case that this property is set.
What's the reason? What is going on here?
Looking on the effects this caused - this cannot be an intended behavior.
Is there an errata or any other documentation?
02-05-2018 09:21 PM
Persist is enabled only when you need to have readback capability while in SelectMap config mode for while using Tandem configuration.
Enabling Persist will result in config interface available even when the FPGA loads the config data and has switched to user mode,
So in your case the config interface is actively reading the data from Flash even when you have completed configuration.
02-06-2018 05:32 AM
I see that the main intended function of PERSIST is the readback capability.
But ug570 (v1.7) page 170 says:
The persist bitstream option (BITSTREAM.CONFIG.PERSIST YES) maintains the configuration
logic access to the multi-function configuration pins after configuration. The persist option
is primarily used to maintain the SelectMAP port after configuration for readback access,
but persist can be used with any configuration mode. ...
I see no reason why the FPGA is periodically requesting something from the flash. Further the result is corruption of configuration memory. The effects I had from this was a GTY-QPLL going out-of-lock while QPLLLock was set AND QPLLfbclklos was set! These are a contradicting states. I also had the issue that suddendly after a couple of minutes (after configuration was finished) INIT_B dropped low. The internal status register did NOT indicate a CRC error. Also the internal INIT_B pin was stated as '1' while the external was states as '0'.
Therefore this seems to be a very odd problem and not a normal operational state of the device. And this is caused just by setting PERSIST to yes.
02-06-2018 03:49 PM
That's exactly the reason we dont recommend using PERSIST in master modes SPI/BPI.
UG470 v1.12 Pg 128 has more explicit statement
PERSIST is also not recommended for standard Master
SPI/BPI configuration mode setups. For advanced tandem Master SPI/BPI configuration
mode setups refer to XAPP1179, for the PERSIST option usage
May be we should add that not recommended statement to UG570 too.
02-07-2018 12:37 PM
not recommending PERSIST with Master BPI etc. is
a) the exact opposite of what ug570 says
b) a nice euphemism for the observed behavior ;-)
The CR is filed : CR 994238