11-08-2019 04:31 AM
I have the following situation: I get some data into my Artix 7 through a GTP trainsceiver. That coming from the GTP is processed by a proprietary protocol IP. This protocol IP outputs the data contained in the received packets on a parallel port. Now this data goes into my block design that contains a Microblaze and some more prorprietary blocks.
My workflow is this: I export the hardware with Vivado, go over to XSDK, where I update the hardware definition. Then I program the FPGA with bootloop for microblaze. At this point my transceiver and protocol IP are working, I verified the received data with an ILA. The next step is what's causing unstable behavior: When I run the software on the microblaze (run config is set to reset processor only), the protocol IP loses its connection. I measured the RXUSRCLK2 output of the GTP right after I run the software on the microblaze and I get 47 MHz instead of the 62.5 MHz that are supposed to come out. This surely is the cause for the protocol IP losing the connection...but why does this happen?
There is no reset connection between block design on the one side and GTP and protocol IP on the other side.
The protocol IP is following the "done" and "locked" outputs of the GTP, but I'm not sure that's enough.
I use the 7 series GT wizard to generate my GTP instance.
What is a good practice for reset topology in such a case, i.e. GTP, protocol IP and block design with microblaze?
What resets are asserted when I run the software from XSDK? I thought only the debug_sys_reset output of the MB debug module, but there is more happening since my GTP clock outputs are getting messed up during that phase.
11-11-2019 08:40 AM - edited 11-11-2019 08:41 AM
It has to be reset or changed in some manner. In this case it might be possible that some other mechanism is in play. Make sure there is no power supply disturbance that might be doing a backdoor reset. My number one candidate for this is something changing in the clocking settings. See page 146 of UG482 and make sure none of the clock muxes change, RXSYSCLKSEL or RXOUTCLKSEL, and make sure all the dividers are not changed. For RX any change in the RX frequency can change the RXOUTCLK which might affect the RXUSRCLK depending on RXOUTCLK settings. I suggest you try to isolate which instruction in the microblaze is causing error. This will probably be the fastest way to solve this.
11-13-2019 03:40 AM
thanks for your reply. I'll have a look at my power rails then, while I step through the main function. Do you by any chance know what exactly happens in the two scenarios of the XSDK run configuration: "Reset processor" and "Reset entire system"? Which resets are asserted in each case?
And another question: what is a good practice for reset cascading in a single processor system? Should the microblaze be the master? And all other blocks, including MGTs, get their resets from, e.g. the "peripheral_reset" output of the processor system reset block that resets the microblaze (mb_reset)?
Or should the MGTs be the master and the reset chain look like this: MGT -> protocol IP -> block design (including microblaze)?
11-18-2019 10:18 AM
I think I found the problem. From some earlier tests I had a constraint in my xdc file that left unused pins floating (PULLNONE). I removed that line and now the erratic behavior is gone.