Flash memory

[marmeladapk]

I have a problem with booting up the FPGA from flash. I can program the flash just fine (w/ verification) in Vivado, however the FPGA just won't boot from it.

• I can program the FPGA with JTAG and DONE signal goes high
• program_b, init_b, mode[2:0] seem to be in the correct state (they are controlled from MMC, Vivado also confirms their state; master spi is chosen)
• I observed on scope all lines and I didn't observe activity on IO2 and 3, other lines behave as expected (and signals are not swapped AFAICT)
• After init_b goes high I can observe that the FPGA reads the memory using 3 MHz clock. I can see the 0x0B command (fast read) followed by three 0x00 bytes, so it's a read operation from 0 address. First tens of bytes that I could observe are consistent with beginning of .bin file (modulo some problems with spi decoder).
• Signal integrity and voltage levels seem fine. There are some overshoots and crosstalk, however nothing dramatic that could prevent the memory from working (esp. at this speed)
• I replaced the memory chip with one from Sayma 1.0, they behave the same.
• If I try to dump the memory contents to file (in Vivado) the I usually get only 0xFFs in file (but not always! When I flashed 20k of random bits I could dump them just fine)
• During bootup the FPGA tries to read the memory for tens of seconds (even minutes)
• There are no obvious design changes in schematics that could cause this behaviour (but you can double check me).

[gkasprow]

a few ideas:

• make sure that IC35 is disabled
• make sure all resistors to RTM are DNP: R223, R224, R225, R226, R227
• make sure that MMC does not mess up with INIT_B, PROGRAM_B, DONE, you can remove R244, R242, R243
• generate FLASH content with a low-speed setting (1MHz) and QSPI disabled.
• remove the C511 or R253. It is a modification of the Xilinx recommendation, even though it worked in rev1

[marmeladapk]

Ha! I found it! TL;DR: Removing C511 or R253 helps.

We had quite a few red herrings, that's why it took so long to debug it.

We had a proper openMMC config with which the FPGA did not program. However it reacted properly to program_b and init_b signals, started SPI communication and issued correct commands (and memory responded to them). Clock looked correct, though with some smooth falling edges. Data had some pretty high overshoots.

We also had an incorrect MMC config, which (by accident) turned high program_b and reset_n before all voltages were stable. The FPGA then programmed correctly, however all SPI levels were around 2,5V, everything else was the same. It didn't program again when we pulsed program_b. It seems that program_b and reset_n powered 3V3 rail for around 100ms and it caused something to happen which caused lower voltages on SPI (probably some parasitic diode or something).

It turns out that the culprit was crosstalk + high overshoots on data + slow falling edge on clk. For example in this event: most probably there was an additional clock cycle registered (1-clock, 2,3-mosi, miso, 4-cs). With smaller voltages on SPI bus (with incorrect config) clock returned more quickly below threshold and crosstalk was less dramatic bc. of smaller rising edge.

With C511 removed: FPGA programs correctly on both Saymas.

But removing C511 only masks the real problem which are high over- and undershoots (>1 V!) and high crosstalk. in UG570 Xilinx reccomends series resistors to minimalize overshoots. Crosstalk is also pretty bad, QSPI lines travel sometimes for centimeters separated only with minimal gap. They also have much lower rise time than I expected (5 ns).

So overall if we plan to do 2.1 we should simulate and insert those series resistors and space QSPI lines. @gkasprow what do you think?

[gkasprow]

True, The clock line should b routed away from the data line. I overlooked this. Series termination on FLASH side won't harm. In Sayma v1.0 there was no length matching and the clock line was separated from data. I asked you to remove C511 already a few posts above :)

[marmeladapk]

Yes, however there other issues which seemed more probable which I tested first.

[jordens]

Nice!

[jbqubit]

Nice find! I made a v2.1 milestone and tagged the issues made by @marmeladapk.

[marmeladapk]

DNPed R253 until #129 is implemented.