cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
383 Views
Registered: ‎09-10-2019

US+ iBERT different behavior depending on the refclk.

Jump to solution

I get different results using iBERT with different reference clocks for a 10G 10.3125Gbps link.

As explained in the example design, the clk port is connected to the O pin of BUFG_GT. The BUFG_GT's I pin is connected to the ODIV2 (which doesn't div2) of the IBUFDS_GTE4 of the refclk.

A. Refclk=156.25MHz

image.png

I get ~10.300Gbps average without errors.

B. Reflclk = 322.265625MHz

image.png

I get ~10.000Gbps average without errors.

The only difference is the DIV pin of the BUFG_GT is set to (3'b001) to divide/2 the 322 MHz because I get MMCM errors when it's 322MHz.

 

Info: The iBERT module is the only IP that changes. The hardware refclk is correctly programmed at the required refclk.

 

There is no requirement for the clk (the doc says if it's higher than 100Mhz, an MMCM will divide it).

No requirement for the refclk other than using a clock in the list in the GUI.

 

Regards,

 

 

 

 

0 Kudos
1 Solution

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

Hi,

>I found out the RXUSRCLK_FREQ and TXUSRCLK_FREQ clocks are wrong, it's 82.543945MHz instead of the 128.90625MHz defined in the ibert_ultrascale_gty_0.v

This is not good. (Perhaps ... some clocks are not properly constrained )

Would you be able to try the IBERT example design, without any additional timing constraint? 
We can use the Example Design as a start point for your debug.

View solution in original post

10 Replies
Highlighted
Xilinx Employee
Xilinx Employee
325 Views
Registered: ‎03-30-2016

Hi @alexis_jp 

You did not share your device model and XCI file, so I assumed that you are using US+ GTY.

1. I tried to reproduce your report using Vivado 2020.1 with IBERT IP configured as XCI file attached. (ibert_ultrascale_gty_0.xci)
I did not find any error generating IBERT example design with Vivado 2020.1.

2. If you set IBERT line-rate as 10.3125 Gbps in the wizard,
You should use it with 10.3125 Gbps line-rate input signal as configured in the IBERT wizard.
10.000 Gbps input line-rate has a 32150ppm frequency offset from the IBERT configuration, this usecase will not work.
unsupported_ibert_usecase.png

Kind regards
Leo

0 Kudos
Highlighted
Adventurer
Adventurer
318 Views
Registered: ‎09-10-2019

@karnanl

1. Well, that has always been the problem with Xilinx's core.

2. As said in my post, the stimuli link doesn't change.

3. I've been fighting with IBERT for 2 days now

 

Could you tell me why do I get timing for that:

Setup slack: ibert_inst/inst/QUAD[0].u_q/CH[0].u_ch/delay_powergood_inst/gen_powergood_delay.pwr_on_fsm_reg/C

image.png

* https://forums.xilinx.com/t5/Other-FPGA-Architecture/The-problem-about-link-status-in-IBERT/td-p/559951

* https://forums.xilinx.com/t5/Serial-Transceivers/iBert-Clocking-and-bit-rate-problems/m-p/1068550

IBERT gives wrong values, not the link. All the clocks are correct.

 

I'm sure the ref clocks are correct in my board. How can I double check what Vivado compiled? Where does the rate come from? Why do I get 10Gbps while the IBERT is configured as 10.3125Gbps?!

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

Hi @alexis_jp 

 

Now, I understand your previous question.

You did not observe any bit error, you only complain that line-rate calculation on the GUI is not accurate.

 

>I get ~10.300Gbps average without errors.

 

This is expected, GUI should report line-rate at this precision.

 

>I get ~10.000Gbps average without errors.

 

Did you see the same behavior using IBERT example design?

 

>The only difference is the DIV pin of the BUFG_GT is set to (3'b001) to divide/2 the 322 MHz because I get MMCM errors when it's 322MHz.

 

Many parameters inside the IBERT core are set when the core is generated by the wizard.

You may see unexpected results if you modified the input clock frequency.

 

# BTW, I do not see any MMCM in my example design, and I do not see any necessity modifying the clock outside the wizard.

 

Kind regards

Leo

Highlighted
Adventurer
Adventurer
298 Views
Registered: ‎09-10-2019

@karnanl  The wizard doesn't let me the choice of the system clock. What is the requirement of this clock?

As said, the ref clock is correct.

pg196:

image.png

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

Please try this then

External_clock_for_IBERT.png

Highlighted
Adventurer
Adventurer
275 Views
Registered: ‎09-10-2019

@karnanlThank you for your help.

I've been trying many times, checking, double checking all the clocks, I don't get the right link rate..

* Adding the set false path for the *u_ch/delay_powergood_inst/gen_powergood_delay.pwr_on_fsm*

* Removing the div factor (system clock = ref clock)

Now I get 6.6Gbps using 156.25MHz, still no errors.

image.png

image.png

image.png

image.png

I shouldn't be the only person to have this kind of issue.

Could you guide me telling me what I need to check?

Regards,

0 Kudos
Highlighted
Adventurer
Adventurer
263 Views
Registered: ‎09-10-2019

I found out the RXUSRCLK_FREQ and TXUSRCLK_FREQ clocks are wrong, it's 82.543945MHz instead of the 128.90625MHz defined in the ibert_ultrascale_gty_0.v

image.png

image.png

.C_RXOUTCLK_FREQUENCY(128.90625),
.C_SYSCLOCK_SOURCE_INT("QUAD125_1"),
.C_SYSCLK_MODE_EXTERNAL('D0),
.C_SYSCLK_IO_PIN_STD("DIFF_SSTL15"),
.C_DISABLE_SYSCLK_BUF('D1),
.C_SYSCLK_IS_DIFF('D0),
.C_SYSCLK_IO_PIN_LOC_P("UNASSIGNED"),
.C_SYSCLK_IO_PIN_LOC_N("UNASSIGNED"),
.C_SYSCLK_FREQUENCY(156.25),
.C_NUM_QUADS(1),

Do you know why? What should I check?!

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

Hi,

>I found out the RXUSRCLK_FREQ and TXUSRCLK_FREQ clocks are wrong, it's 82.543945MHz instead of the 128.90625MHz defined in the ibert_ultrascale_gty_0.v

This is not good. (Perhaps ... some clocks are not properly constrained )

Would you be able to try the IBERT example design, without any additional timing constraint? 
We can use the Example Design as a start point for your debug.

View solution in original post

Highlighted
Adventurer
Adventurer
203 Views
Registered: ‎09-10-2019

@karnanlProblem solved.

set_property C_CLK_INPUT_FREQ_HZ 156250000 [get_debug_cores dbg_hub]
set_property C_ENABLE_CLK_DIVIDER true [get_debug_cores dbg_hub]

C_CLK_INPUT_FREQ_HZ was wrong, I didn't expect it to have any influence on the IBERT core.

I don't understand why those kind of constraints aren't embedded inside the core and what are the consequences on my other IBERT/VIO/ILAs using different refclk/sysclks.

Thanks for your help.

0 Kudos
Highlighted
Moderator
Moderator
163 Views
Registered: ‎07-30-2007

The IBERT is a very sensitive block and the IP is not designed to be added to other designs.   From the IBERT product guide:  The recommended and supported flow is to use the IBERT as-is without modifications.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------