cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
268 Views
Registered: ‎01-19-2012

Help understanding cplllockdetclk & rxuserrdy

Jump to solution

Hi there, 

I have a Kintex-7 and am simulating two GTX RX channels to run at a 5.0 GPbs line rate, with a shared 312.5 MHz reference clock that is going to the CPLL of a single quad. I'm also using the included reset finite state machines in my design.

My first question is, is the cplllockdetclk_in port required? When I tie this port to zero and simulate, both channels cplllock_out signals go high, indicating that the CPLL is locked. However, the FSMs get stuck in the ASSERTALLRESETS state because CPLLREFCLKLOST goes high. According to UG476 page 50, this clock is optional.

This clock is required only when using the CPLLFBCLKLOST and CPLLREFCLKLOST ports.
It does not affect the CPLL lock detection, reset and power-down functions.

Adding a 100 MHz reference clock to this port makes everything run fine, but this goes against the above statement in the user guide. Is the presence of this clock required only because of the included FSMs design, or am I not understanding something more fundamental.

Also, in my simulation I don't drive rxuserrdy_in at all, it's tied to zero, and both rxresetdone_out and the FSM_RESET_DONE signals both go high. I do, however, drive DATA_VALID_IN, which is again, a FSM specific signal. But according to the user guide again, page 72 it says

In either sequential mode or single mode, the RX reset state machine does not reset the PCS
until RXUSERRDY goes High. The user should drive RXUSERRDY High after these
conditions are met

So again, does the FSM DATA_VALID_IN signal take the place of the rxuserrdy_in signal somehow?

Thank you.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
214 Views
Registered: ‎03-30-2016

Re: Help understanding cplllockdetclk & rxuserrdy

Jump to solution

Hello @kwiatlab 


>This clock is required only when using the CPLLFBCLKLOST and CPLLREFCLKLOST ports.
>It does not affect the CPLL lock detection, reset and power-down functions.

I think that statement is still correct.
UG476 is a transceiver user-guide, that explains transceiver macro features and behavior.
On the other hand, TX/RX FSM is Reset Helper block. These are additional modules in the gt wrapper that created to help user controls transceiver macro.
Transceiver_macro_and_moduless_in_wrapper.png

Since reset helper block use CPLLFBCLKLOST, you need to supply a clock for cplllockdetclk.
BTW, if you generated GTX example design, this cplllockdetclk clock will be named as SYSCLK_IN. (which also connected to DRP clock)
You need to supply a free-run clock for these clocks, to run GTX transceivers properly.
SYSCLK_IN.png

>In either sequential mode or single mode, the RX reset state machine does not reset the PCS
>until RXUSERRDY goes High. The user should drive RXUSERRDY High after these
>conditions are met

>So again, does the FSM DATA_VALID_IN signal take the place of the rxuserrdy_in signal somehow?

PG168_FSM_chart.png

No, Please see also flowchart described in PG168.
I would not recommend setting a constant "0" to rxuserrdy_in, since it will make your GTX PCS not initialized.
It may work on simulation, but I would not be surprised if you see some issues on HW.

RTL_FSM.png

You can also see the RTL of RX FSM (see above).
Even if GTX PCS is not initialized,  when you asserted Data valid (or set as a constant "1"), FSM will set its state as FSM_DONE, since the system indicated that received data is okay.
Data valid is only used as an indicator to monitor the RX link. You can customize the data valid indicator based on your system design.

I hope this helps.

Kind regards
Leo

View solution in original post

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
215 Views
Registered: ‎03-30-2016

Re: Help understanding cplllockdetclk & rxuserrdy

Jump to solution

Hello @kwiatlab 


>This clock is required only when using the CPLLFBCLKLOST and CPLLREFCLKLOST ports.
>It does not affect the CPLL lock detection, reset and power-down functions.

I think that statement is still correct.
UG476 is a transceiver user-guide, that explains transceiver macro features and behavior.
On the other hand, TX/RX FSM is Reset Helper block. These are additional modules in the gt wrapper that created to help user controls transceiver macro.
Transceiver_macro_and_moduless_in_wrapper.png

Since reset helper block use CPLLFBCLKLOST, you need to supply a clock for cplllockdetclk.
BTW, if you generated GTX example design, this cplllockdetclk clock will be named as SYSCLK_IN. (which also connected to DRP clock)
You need to supply a free-run clock for these clocks, to run GTX transceivers properly.
SYSCLK_IN.png

>In either sequential mode or single mode, the RX reset state machine does not reset the PCS
>until RXUSERRDY goes High. The user should drive RXUSERRDY High after these
>conditions are met

>So again, does the FSM DATA_VALID_IN signal take the place of the rxuserrdy_in signal somehow?

PG168_FSM_chart.png

No, Please see also flowchart described in PG168.
I would not recommend setting a constant "0" to rxuserrdy_in, since it will make your GTX PCS not initialized.
It may work on simulation, but I would not be surprised if you see some issues on HW.

RTL_FSM.png

You can also see the RTL of RX FSM (see above).
Even if GTX PCS is not initialized,  when you asserted Data valid (or set as a constant "1"), FSM will set its state as FSM_DONE, since the system indicated that received data is okay.
Data valid is only used as an indicator to monitor the RX link. You can customize the data valid indicator based on your system design.

I hope this helps.

Kind regards
Leo

View solution in original post

Highlighted
Adventurer
Adventurer
183 Views
Registered: ‎01-19-2012

Re: Help understanding cplllockdetclk & rxuserrdy

Jump to solution

Thank you for the detailed answer, it helps a lot. A quick question though, you said

BTW, if you generated GTX example design, this cplllockdetclk clock will be named as SYSCLK_IN. (which also connected to DRP clock)
You need to supply a free-run clock for these clocks, to run GTX transceivers properly.

My generated code has both SYSCLK_IN and cplllockdetclk ports. The cplllockdetclk has a requirement that it must be independent of the CPLL clock, are these really the same clocks, and does SYSCLK have that same requirement?

Thanks again.

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
137 Views
Registered: ‎03-30-2016

Re: Help understanding cplllockdetclk & rxuserrdy

Jump to solution

Hello @kwiatlab 

I mean in the example design SYSCLK/DRPCLK/CPLLLOCKDETCLK are merged into one clock port (SYSCLK).
Something like this:
All_merged_as_sysclk.png

Kind regards
Leo