cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
andrei.tunea
Observer
Observer
577 Views
Registered: ‎04-09-2013

Reset sequence and synchronization for block design with Microblaze + GTP transceivers (on an Artix 7)

Dear forum,

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.

 

0 Kudos
3 Replies
roym
Moderator
Moderator
501 Views
Registered: ‎07-30-2007

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. 




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


0 Kudos
andrei.tunea
Observer
Observer
464 Views
Registered: ‎04-09-2013

Hi roym,

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)?

 

0 Kudos
andrei.tunea
Observer
Observer
433 Views
Registered: ‎04-09-2013

Hi roym,

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.

Best regards,

Andrei