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: 
Explorer
Explorer
6,926 Views
Registered: ‎04-24-2014

Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution

Currently, I'm running some simulations of a GTXE2_CHANNEL primitive.

 

I found that the in simulation the CPLL locked signal is assign before the clock is active and before it's stable.

 

GTXE2_CPLL_Locked_async.PNG

 

I performed a powerdown / powerup cycle and after some time gtx_cpll_locked_async is asserted. Refering to the UG476 manual:

 

This active-High PLL frequency lock signal indicates that the
PLL frequency is within predetermined tolerance. The transceiver
and its clock outputs are not reliable until this condition is met.

 

The CPLL output clock (in my case: TXOUTCLK -> GTX_TX_RefClockOut) needs still some time to propagate through the design and even after that, it's not stable!

 

So...

  • is it a simulation bug?
  • is the documentation not precise enough?
  • is the hardware behaving in the same way?

Here are some generic, that could be interesting to answer my question:

SIM_RESET_SPEEDUP	=> "TRUE",	-- set to "TRUE" to speed up simulation reset
SIM_CPLLREFCLK_SEL	=> "111",	-- GTGREFCLK (GTX_RefClockGlobal) is used
                                                                            
TX_XCLK_SEL		=> "TXOUT",
RX_XCLK_SEL		=> "RXREC",

 

Regards

    Patrick Lehmann

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Explorer
Explorer
11,300 Views
Registered: ‎04-24-2014

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution

I found the documentation lines, why TXOUTCLK stops after reset:

 

UG476 [v1.10] - page 142; bullet 2

 

TXOUTCLKSEL = 3'b010: TXOUTCLKPMA is the divided down PLL clock after the TX phase interpolator and is used by the TX PCS block. This clock is interrupted when the PLL is reset by one of the related reset signals.

 

I'll discuss this in my team. Because we have to cope with a clock that can be disabled ... if a reset is required.

 

@venkata Thanks for your support.

 

 

0 Kudos
7 Replies
Moderator
Moderator
6,659 Views
Registered: ‎02-16-2010

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution
Check figure 3-28, you can observe that the refclk out from CPLL goes through few other blocks in PMA before it comes out as TXOUTCLK. I think you are observing this delay.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Explorer
Explorer
6,653 Views
Registered: ‎04-24-2014

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution
How should I deal with it on chip? What is the max delay on a real FPGA?

CPLL_LOCKED should be used to hold GTX in reset until clock is stable. But when I release this to early GTX starts with a dirty clock, doesn't it?
0 Kudos
Moderator
Moderator
6,637 Views
Registered: ‎02-16-2010

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution
There is no real specification for max delay of the path. You could delay the reset signal going to MMCM to ensure the TXOUTCLK is stable when reset is released.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Explorer
Explorer
6,632 Views
Registered: ‎04-24-2014

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution
I figured out some new details: TXOUTCLK depends on GTX_Reset. There is a ClockMux or ClockOutputEnable circuit somewhere in GTX. CPLL_LOCKED is assigned but TXOUTCLK stays zero if GTX_Reset is not deasserted.

My design has no MMCM that needs to be reset, but the locked signals is used as clockenable on some user logic parts :)
0 Kudos
Explorer
Explorer
6,562 Views
Registered: ‎04-24-2014

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution

I did some more simulations and discovered other weird things ...

 

GTXE2_Reset_disables_clock.PNG

 

When GTX_Reset (GTX_RX_Reset and GTX_TX_Reset) is enabled, it immediately disables GTX_UserClock. This seams to be a async operation. Moreover it also immediately disables GTX_RX_ResetDone and GTX_RX_ResetDone.

 

This is definitivly a bug, because both ResetDone signals are synchronous to UserClock.

0 Kudos
Moderator
Moderator
6,542 Views
Registered: ‎02-16-2010

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution
When you apply GTTXRESET, TXOUTCLK will be stopped. TXUSRCLK will stop later.

Are you probing at the GT primitive interface level?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
11,301 Views
Registered: ‎04-24-2014

Re: Kintex-7 simulation bug? - GTXE2 Channel PLL locked signal before clock is stable.

Jump to solution

I found the documentation lines, why TXOUTCLK stops after reset:

 

UG476 [v1.10] - page 142; bullet 2

 

TXOUTCLKSEL = 3'b010: TXOUTCLKPMA is the divided down PLL clock after the TX phase interpolator and is used by the TX PCS block. This clock is interrupted when the PLL is reset by one of the related reset signals.

 

I'll discuss this in my team. Because we have to cope with a clock that can be disabled ... if a reset is required.

 

@venkata Thanks for your support.

 

 

0 Kudos