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

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

  • 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?

  • 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

  • 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.

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

  • 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.

  • 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.