Post Go back to editing

AD9371 Framer lane FIFO read/write pointer delta has changed

Category: Hardware
Product Number: AD9371

When we reinitialize our JESD interface using _jesdInit(), we see the Rx Framer status of 0x7e rather than 0x3e about 2% of the time, indicating that the "Framer lane FIFO read/write pointer delta has changed." I have seen a few other similar inquiries but have not seen a clear answer to those questions so I am posting this one. Also, I have looked over the JESD204B Debugging document but I don't see what is causing our problem. I would like to know: 1) What causes this error in the framer path, 2) Is this error clear-on-read or do we need to clear it another way, 3) Other questions submitted indicate that their link appears to be running fine when this error is indicated so what are the issues with continuing to use the link rather than clearing the error. BTW, the Xilinx JESD204B cores on the opposite side of the link do not show any errors. Any help would be appreciated. Thank you.

Parents
  • What is the SYSREF Frequency you are operating with ? As you are getting the RX framer status as 0x7e and it indicates  that the "Framer lane FIFO read/write pointer delta has changed". Means there is some issue with the deterministic latency.

    Ensure  that the SysRef is reaching the FPGA and the Device at the same time.

    There could be Deterministic latency uncertainty (DLU) issue which is the LMFC skew in the JESD204B system and it is  determined by the difference between the earliest and latest possible capture of SYSREF in the system.

    DLU can be minimized by ensuring that setup and hold time are met for each SYSREF/DCLK pair and by minimizing the inter-pair distribution skew.

    Refer to the MS-2677 Section(Page 54) of the Document attached where its mentioned about the deterministic latency uncertainty and how to minimize it .

    https://www.analog.com/media/en/technical-documentation/technical-articles/JESD204B-Survival-Guide.pdf

  • Thank you for responding.

    Our SYSREF is 1.2MHz. Fs = 307.2MSPS; S = 1; K = 32.

    We are seeing Rx frame status of 0x7e about 2% of the time. There is a dedicated SYSREF and DCLK to each device. There is about 0.6nsec difference between the time that SYSREF reaches the AD9371 and the time that it reaches the FPGA. The DCLK for each device precedes the SYSREF at each device by about 0.2nsec. This easily meets the Th for the AD9371. 

    We could try to use the Analog Fine Delay in the AD9528 to equalize the paths to the AD9371 and the FPGA but I don't think that it is the problem but I would like your opinion.

Reply
  • Thank you for responding.

    Our SYSREF is 1.2MHz. Fs = 307.2MSPS; S = 1; K = 32.

    We are seeing Rx frame status of 0x7e about 2% of the time. There is a dedicated SYSREF and DCLK to each device. There is about 0.6nsec difference between the time that SYSREF reaches the AD9371 and the time that it reaches the FPGA. The DCLK for each device precedes the SYSREF at each device by about 0.2nsec. This easily meets the Th for the AD9371. 

    We could try to use the Analog Fine Delay in the AD9528 to equalize the paths to the AD9371 and the FPGA but I don't think that it is the problem but I would like your opinion.

Children
No Data