UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer jfcliche
Observer
10,788 Views
Registered: ‎12-01-2010

7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

Hi. I Use a Ethernet 1000BASE-X PCS/PMA 14.3 core (Vivado 2014.3/Win7 64) on a Kintex 7K420-2 to talk to a copper SFP module, and the link fails to initialize most of the time. I narrowed down the problem by implementing only the GTX transceiver wizard code from this core (part of a freshly generated example design) and saw that the TX startup state machine failing to complete initialization sequence, so it has apparently nothing to do with the core (indeed, when it randowmly succeeds to initialize, my ethernet link works perfectly).

 

I added a few signals to the standard core_name_TX_STARTUP_FSM.vhd and discovered that the state machine is stuck while waiting for the CPLL to unlock. The core generator code have correctly connected the CPLL_RESET and CPLL_LOCK signals to the state machine. I use a buffered version of the GTX 125 MHz reference clock (straight from the IBUFDS_GTE2) as a stable clock, so it should be stable indeed. I tried another clock (a 156.25 MHz clock from another IBUFDS_GTE2) to no avail. Additional reset pulses do not help, even if those are sent much later, after any post-config action has time to complete.  Simulations work perfectly, though, but the GTX behavior is accelerated to I'm not sure this is representative of reality.

 

The core's code add a reset pulse shaping circuit to the CPLL reset input of the GTX. From reading the code, it seems to ensure cross domain synchronization, minumum pulse length and prevent multiple pulses to be generated too closely. As a test, I bypassed the circuitry completely and the reset sequence worked. I'm not sure why, as the core's code seems valid at first glance.

 

It's hard to beleive that the CPLL would lock too rapidly (within 2 clocks) and cause this problem. My clocks seem ok. Simulation works. I use the example design constraints. My clocks should be clean (coming from a low phase noise external PLL).  I must be missing something, as this GTX code seems to be standard. I would like to use the core without having to change some of its automatically-generated source code, so I'm looking for a higher-level solution than patching the core's GTX code.

 

Anybody has an insight on this, debugging suggestions or  known working configurations using similar set-ups?

 

Thanks,

 

Jean-Francois

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
17,606 Views
Registered: ‎02-06-2013

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

Hi Jean,

 

We have seen this issue with V14.3 core causing link up issue and releasing a AR soon.

 

Please do the changes in below files and test.

 

  • gtwizard_gt
    1. Replaced drpclk_in with cplllockdetclk_in. cplllockdetclk_in is tied to the the stable clock used in reset fsms
  • gtwizard_init
    1. Remove cpll_reset_sync
    2. Connect gt0_cpllreset_i to gt0_cpllreset_in port of gtward_i instance
  • Block level xdc
    1. Remove this false path constraint

set_false_path -to [get_pins -hier -filter { name =~ */gtwizard_inst/*/cpll_reset_sync/reset_sync*/PRE } ]

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
7 Replies
Xilinx Employee
Xilinx Employee
17,607 Views
Registered: ‎02-06-2013

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

Hi Jean,

 

We have seen this issue with V14.3 core causing link up issue and releasing a AR soon.

 

Please do the changes in below files and test.

 

  • gtwizard_gt
    1. Replaced drpclk_in with cplllockdetclk_in. cplllockdetclk_in is tied to the the stable clock used in reset fsms
  • gtwizard_init
    1. Remove cpll_reset_sync
    2. Connect gt0_cpllreset_i to gt0_cpllreset_in port of gtward_i instance
  • Block level xdc
    1. Remove this false path constraint

set_false_path -to [get_pins -hier -filter { name =~ */gtwizard_inst/*/cpll_reset_sync/reset_sync*/PRE } ]

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Observer jfcliche
Observer
10,692 Views
Registered: ‎12-01-2010

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

Hi Satish,

 

Thanks for the quick answer. I implemented your recommended changes and it works. The TX link seems to come up all the time after multiple configurations and manual resets.

 

I also implemented a simplified version of the fix that works for me:

 

  • In the gtwizard_gt instance, assign CPLLLOCKDETCLK to '0' so I can set independent_clock to a clock derived from GTREFCLK.
  • On the 1000BASE-X/SGMII core instance in the user code, use the same clock for both independent_clock and drp_clk. In my case I use a BUFG'ed version of GTREFCLK.

This also works, but let me know if it's a bad idea (apart from being a less generic solution). For instance, the CPLL_RESET is still resync'ed (to the same clock) and the false path is still there.

 

I have a few questions:

  • For the benefit of my education, can you provide an explanation of why the original code did'nt work? The cross-clock-domain sync'ing seemed to have been done properly.
  • What is the recommended way to handle modified core source files. Any regenerate will erase those changes, and I don't usually keep the products in my revision control. Should I use a VHDL CONFIGURATION to override my own code?

Also, in the gtwizard_gt code, it seems a bit wasteful to use a BUFG to clock only a few registers. Using a BUFH might be better. Or even better, we could provide our own buffered version of GTREFCLK. I myself use such a clock elsewhere.

 

I will now try the solution on a full system to see if real ethernet communications links come up, not just the core.

 

JF

 

0 Kudos
Observer jfcliche
Observer
10,647 Views
Registered: ‎12-01-2010

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

I did more thorough testing of the solution proposed above, where all the core's reset logic is effectively operated from a single stable clock, and that solution does *NOT* completely solve the problem of intermittent startups. Here are the results:

 

1) If I use a 125 MHz stable clock generated using a MMCM locked to the 125 MHz GTX reference clock, the core or GTX logic will seize up, and oddly, core resets won't be able to recover from this state. This is the case even if the core is held in reset until the MMCM is locked.  To clarify, note that this MMCM is not the one used to generate the userclks. I suspect that prior to locking the MMCM generates clocks that violates timing, and the the core's reset logic gets in invalid states not handled by reset, or that the GTX freezes up because that clock is also used for the the DRP port. Gating the clock until lock is acheived solves that problem, but I have reverted to using a buffered verison of the GTX reference clock as a really stable clock. Maybe the documentation should state that a MMCM cannot be used to generate a stable clock.

 

2) Using the 125 MHz GTX reference as a stable clock, I observed that with the proposed solution the core will fail to complete the GTX TX iniitialization sequence randomly after FPGA configuration about 3% of the time. I've done hundreds of FPGA configurations to confirm this. For this test, I do not apply any resets to the core after configuration, assuming that the core handles that.

 

My question:

 

Is it required to reset the 1000BASE-X/SGMII core after FPGA configuration, and if so, for how long?

 

Thanks,

 

JF

 

 

 

0 Kudos
Contributor
Contributor
10,614 Views
Registered: ‎08-12-2008

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

 

>We have seen this issue with V14.3 core causing link up issue and releasing a AR soon.

>...

>Satish

 

Can you elaborate on this?  I'm at 14.2 and was about to upgrade to 14.3, but now I'm hesitant to do so without further knowledge.  Also, is there any updates to this core in the 2014.4 release?

 

 - Woody

0 Kudos
Xilinx Employee
Xilinx Employee
10,609 Views
Registered: ‎02-06-2013

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

HI

 

This failure was introduced in the v14.3 release in 2014.3 due to cpll reset changes in GTWIZARD_GT

This issue is fixed in the v14.3 (Rev. 1) with Vivado 2014.4.

 

You can directly upgrade to Vivado 2014.4 or to work around the failure in the v14.3 core in Vivado 2014.3, lock the core and make the changes mentioned in my first post.

 

For information on locking the core so that the changes are not over-written, see (Xilinx Answer 57546).

 

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
10,601 Views
Registered: ‎02-06-2013

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution

Hi JF

 

Why do you want to use your own solution when the workaround provided is working fine,any specific reason.

 

You can see the reason for the issue and how to do the modification in my other post.

 

If revision control is the issue for making the changes,please upgrade to Vivado2014.4 which will be releasing on 24th nov where the fix is included.

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Observer jfcliche
Observer
10,592 Views
Registered: ‎12-01-2010

Re: 7 series GTX: TX reset sequence fail on 1000BaseX PCS/PMA core. CPLL fail to unlock?

Jump to solution
Hi Satish,

> This issue is fixed in the v14.3 (Rev. 1) with Vivado 2014.4.

Good. I will upgrade. It's just a few days away.

> For information on locking the core so that the changes are not over-written, see (Xilinx Answer 57546)

Thanks. Didn't know that one. That AR might be useful in the future.

> Why do you want to use your own solution when the workaround provided is working fine,any specific reason.

You are right, I don't have a good reason not to use your solution. I just wanted to minimize core code change, but once I modify a file I might modify all of them as well. So far as my testing goes, your solution works well, as long as I hold the core in reset at startup for a while ( I hold it for about 27 ms in my case) . If I don't reset at startup,  I have 2-3% of initialization failure rate. I am building an array of 160 FPGAs to these failure rates become significant.

Note that having cplllockdetclk port of the GTX instance connected to the stable clock prevents me from using the GTX reference clock as stable clock. DRC at bitstream generation complains that this does not make sense, and it is right. Since the CPLL reference/feedback loss-of-signal detection is not connected to anything in the core, it would be better to tie the GTX input port to '0' to eliminate this unnecessary hardware constraint. That is what I do now so I can use by GTX reference clock to run everything.
 
Also, as mentioned earlier,  I cannot use a MMCM to generate a clock for independent_clock and drp_clk, even if I hold the core in reset until the MMCM is locked. This locks up the internal machinery of the core or the GTX, and resets do not recover from this. 


Thanks for helping on this,

Jean-François
0 Kudos