TI-JESD204-IP: zcu102_8b10b IP works fine for 8 lanes but gives rx_lane_invalid_eomf_err_count

Trushal Alshi

Part Number: TI-JESD204-IP

Tool/software:

Hi all,

We have ported ref design ZCU102 to ZCU104 FPGA (Vivado 23.1). The simulation works fine as per TI-JESD204-IP: Simulation of loopback design in Vivado - Data converters forum - Data converters - TI E2E support forums

It works perfect for 8 lanes. But when changes the number of lanes e.g 4, all parameters work fine but rx_lane_invalid_eomf_err_count value increases intermittently. The line rate has been set to 6.25 Gbps with reference clock tried both with 156.25 Mhz and 78.125 Mhz. In both cases, we see the the above error count rising. No conflicting symptoms seen on any other signal. Please find the waveform and jesd_link_param.vh

-Thanks

2 months ago

0 Trushal Alshi 2 months ago

Prodigy 100 points

One more observation add here. If the Line rate is maintained at 12.5 Gbps, no above errors seen but wondering how such line rate is validated for 4 lanes. Is it that the Line Rate needs to be mentioned considering 8 lanes irrespective of actual number of lanes?

0 Ameet Bagwe 2 months ago in reply to Trushal Alshi

TI__Intellectual 1760 points

Hi Trushal,

Kindly list all the changes made to the project (RTL files, transceiver settings, etc) when you transitioned to the 4lane 6.25Gbps design.

Regards,

Ameet

+1 Trushal Alshi 2 months ago in reply to Ameet Bagwe

Prodigy 100 points

Hi Amit,

We could simulate successfully. A mismatch in frequencies of sysref, ref_clk and free-running DRP clk (displayed by default in xcvr wizard) was causing eof and eomf errors in simulations. e.g. at 5 Gbps, ref_clk input freq of 62.5 Mhz would not give these errors unlike with ref_clk = 125 Mhz. We are facing the challenges in on board testing. The external loopback is giving eomf errors now. Please find the .xci file attached. The Trx IP was upgraded. Line rate = 10 Gbps, PLL Type QPLL0, Actual reference clock=125 Mhz. Sysclk= 125 Mhz. We are receiving the data but see eomf error count max out to 'f'. cfg_rx_buffer_release_delay was set to 0. Hope to get some solution for this issue.

+1 Trushal Alshi 2 months ago in reply to Trushal Alshi

Prodigy 100 points

we tried same with disabling determinist latency as well, no relief though.

+1 Trushal Alshi 2 months ago in reply to Trushal Alshi

Prodigy 100 points

Hi Amit, just a heads up. We could resolve eomf_errors by connecting the tx_sys_ref and rx_sys_ref = mgt_rx_usrclk2. It seems the ppm difference in sys_clock and the actual mgt_refclk_p causes the eomf issue over the period as sysref was derived from sys_clock. Hope I am correct.

0 Trushal Alshi 2 months ago in reply to Trushal Alshi

Prodigy 100 points

One more observation is that the sys_clk should have frequency as LineRate/80 ( for datawidth of 64). So according to LineRate sys_clk should also change along with ref_clk. During simulations, we tend to miss out this much needed change.