Hi Dave and casper. > We've been experiencing some flakey behavior on some ROACH boards. The > symptom was that data written to a software register after programming a bof > file would sometimes not read back properly (we got all 0's).
I know this is a fairly old issue but one that turns out to crop up even in bootstrap option C (ie at bus speeds of 66MHz). I'll summarize the symptom again: Sometimes when you program the FPGA the configuration seems not to 'take; all you get are '0's on reads. It turns out to be a really weird problem. Basically the configuration works fine, the CRC checks out, the FPGA makes it through its internal boot sequence, BUT (and it is a big but) it 'forgets' to enable the IOs. So basically your FPGA is configured ok, but all the IOs are in tri-state. Why this happens, I do not know. However, you can check to see that is has happened by doing a jtag FPGA status read using the impact tools. What you'll see in the log is this: status of GTS_CFG_B : 0 This indicates that the IOs are stuck in tri-state. This is the only difference between a configuration that works and one that returns all zeros. There is a work-around, which involves telling the FPGA to enable the IOs earlier in the boot sequence. You do this by modifying the following line in XPS_ROACH_base/etc/bitgen.ut: -g GTS_cycle:5 to -g GTS_cycle:2 This fix seems to work for us. The reason why the original setting occasionally doesn't work is a mystery to me. The other interesting thing is that it has only crept in recently ie in newer boards. This makes me think that it could be a silicon issue. That is just speculation. I will be pushing this change up to the casper kat repo some time. (when I can get git to work) Kind regards, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: [email protected]
