cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
a8814
Observer
Observer
546 Views
Registered: ‎09-24-2014

GTP ::: 50% power up success rate

Jump to solution

Artix 7
Vivado 2018.2
212.5 MHz reference clock
100.0 MHz stable clock
3.1875 Gbps "from scratch" protocol
Two byte boundary comma alignment - plus and minus
Shared logic in example design

I've created an RX-only transceiver and am finding that about half the time it powers up and works fine, while the other half it detects disparity and not-in-table errors and asserts RXBYTEREALIGN. Those assertions happen frequently, but not regularly. In between them I can see data that I expect.

If the design powers up OK, I can freely disconnect and reconnect the source and it always seems to recover and align itself. Very robust. If the design does not power up OK, I can never seem to get it to properly align with disconnects and reconnects.

I'm not issuing any resets other than the ones that the RX STARTUP FSM issues in the example design. Things I've tried, unsuccessfully:

1. Holding soft reset at power up. Results in RX STARTUP FSM getting stuck at ASSERT ALL RESETS state.

2. Holding GTRXRESET at power up. No change in behavior.

3. Connecting not(RXBYTEISALIGNED) to RXMCOMMAALIGNEN and RXPCOMMAALIGNEN. Made problem worse.

4. IBERT. Looked like plenty of margin.

5. Power up sequencing is good. Power and clocks look stable.

What variables or signals should I be examining at power up? What am I missing?

0 Kudos
1 Solution

Accepted Solutions
a8814
Observer
Observer
244 Views
Registered: ‎09-24-2014

I did a build that routed a test point input to SOFT RESET and a test point input to GTRXRESET. When it powered up in the failed state, I found that SOFT RESET made it recover, but GTRXRESET did not. The key here is that the reset was issued after RX FSM DONE is asserted. Previous attempts to issue SOFT RESET immediately after configuration were not successful.

So now I wait until I see RX FSM DONE and then issue a SOFT RESET. I've been testing all morning and have not seen a fail yet with this fix in.

View solution in original post

9 Replies
CircuitPeon
Newbie
Newbie
487 Views
Registered: ‎03-01-2021

We're seeing this behavior again on a new project. We had the design functioning and then these errors started to show and prevented us from staying locked on to the source. 

0 Kudos
roym
Moderator
Moderator
463 Views
Registered: ‎07-30-2007

Does the problem go away with "any byte" boundary?  Are there always an even number of bytes between the commas?  Which refclk do you use?




----------------------------------------------------------------------------
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
a8814
Observer
Observer
454 Views
Registered: ‎09-24-2014

Thank you for the reply. Up until yesterday I had been using any byte boundary. I only recently switched to two-byte. No change with either arrangement.

I'm using refclk 0 routed through PLL 0.

0 Kudos
roym
Moderator
Moderator
452 Views
Registered: ‎07-30-2007

Does this only fail on a new power up?  Is it only fixed by a reconfiguration?




----------------------------------------------------------------------------
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
a8814
Observer
Observer
451 Views
Registered: ‎09-24-2014

It seems to be happening only on power on. For instance, if I program a BIT file into the device it configures and works fine. But if I take the same design and load the MCS it will fail.

0 Kudos
a8814
Observer
Observer
451 Views
Registered: ‎09-24-2014

I should add that there's a reset button on the board, which resets the FPGA power. If I hit that button quickly (we've scoped the power, which doesn't completely go to 0) then it works. But if we hold the button for a few seconds, it won't come up properly.

0 Kudos
roym
Moderator
Moderator
436 Views
Registered: ‎07-30-2007

This seems to be an issue with the design advisory below.  This should be fixed in the newer code releases but you seem to be running into it. There is code attached to the advisory that can fix it.

   https://www.xilinx.com/support/answers/59294.html 




----------------------------------------------------------------------------
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
a8814
Observer
Observer
279 Views
Registered: ‎09-24-2014

The "CPLL RAILING" file (VHDL) that's created seems to have the equivalent code fix. However, its outputs are assigned to signals that aren't connected anywhere. I've added this into the "SUPPORT" file that instantiates "CPLL RAILING":

gt0_pll0reset_t <= commonreset_i or gt0_pll0reset_i or cpll_reset_pll0_q0_clk0_refclk_i;
gt0_pll0pd_t    <= cpll_pd_pll0_q0_clk0_refclk_i;

I noticed that these assignments are present in the Xilinx example design when both the TX and RX are activated but missing when only RX is used.

But alas the behavior remains unchanged. 

0 Kudos
a8814
Observer
Observer
245 Views
Registered: ‎09-24-2014

I did a build that routed a test point input to SOFT RESET and a test point input to GTRXRESET. When it powered up in the failed state, I found that SOFT RESET made it recover, but GTRXRESET did not. The key here is that the reset was issued after RX FSM DONE is asserted. Previous attempts to issue SOFT RESET immediately after configuration were not successful.

So now I wait until I see RX FSM DONE and then issue a SOFT RESET. I've been testing all morning and have not seen a fail yet with this fix in.

View solution in original post