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.

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

  • Also, I would like to know if the "pointer delta change" error is clear-on-read or if it is cleared some other way.


  • Can you try reading the FIFO depth using the MYKONOS_getDeframerFifoDepth? Make sure that it is not close to the boundaries(0 or 127). If its close, then try adjusting the LMFC offset such that the FIFO is close to the mid depth.

    Also, can you try at lower sampling rates and JESD lane rate? Make sure that the sysref frequency is lesser than Fs/64.

  • I am not sure of the value of reading the DeframerFifoDepth when our problem is on the Rx Framer path. Am I missing something? 

    The FPGA JESD cores do not have an equivalent measurement on that side of the link.

    We can't change the sample rate easily. There are too many other circuits related to the clocks. Our Fs=307.2MSPS and SYSREF = 1.2MHz which is Fs/256.

  • Can you check whether the SYNC signal is High or toggling ?  

    The framer status 0x7e says that it is in Data phase. The reasons can be due to 

    • Invalid setup and hold time of periodic or gapped periodic SYSREF or SYNC~ signal.
    • Link parameter conflicts.
    • Character replacement conflicts.
    • Scrambling problem, if enabled.
    • Lane data corruption, noisy or jitter could force the eye diagram to close.
    • Spurious clocking or excessive jitter on device clock.
  • The SYNC signal is low for the CGS phase and then goes high after that and stays high. That is what I would expect for the ILAS and data phases. I believe that the link parameters are good since the link passes the ILAS phase without any errors. It seems that the other issues would be cause the link to be unstable but we have run several tests for multiple hours (14 to 15) and a good link stays good. I have monitored the SYNC signal during that time and it never transitions low. Again, we only see the Frame = 0x7e about 2% of the time.

    These symptoms point to a start up problem and I am having a hard time pinpointing the source of the problem. 

    One other data point: the FPGA cores were configured to look at the falling-edge of SYSREF but the Mykonos is looking at SYSREF on the rising-edge. Thinking that the setting could make a difference, we made a test load of the FPGA to look at SYSREF on the rising-edge and ran 100 test iterations. We saw the same 2% failure rate.

    Is the "pointer delta change" error clear-on-read or if it is cleared some other way?

  • No , we cannot clear the pointer delta change error.

    Is the "pointer delta change" error clear-on-read or if it is cleared some other way?

    What is the Deframer Status you are observing ? 

  • Sorry for the delay. I have been out of the office.

    After we initialize the JESD interface (Mykonos and Xilinx JESD204B cores) the Deframer status is 0x69 most of the time. The software reconfigures the Mykonos JESD interface and then the status is 0x28. This happens almost 100% of the time now.

    Here is an example of what we are doing:

    07:03:49:957 cpp:_jesdLinkStatus:1550: AD9731 Mykonos JESD composite status false: Bad status read from DeFramer: 0x69!
    07:03:49:957 AD9731 Mykonos JESD interface status invalid after initialization, re-trying
    07:03:49:957 MYKONOS_enableSysrefToRxFramer()


    07:03:49:958 MYKONOS_enableSysrefToDeframer()

    07:03:49:958 MYKONOS_resetDeframer()

    07:03:49:958 MYKONOS_enableSysrefToDeframer()

    07:03:50:057 cpp:_jesdLinkStatus:1539: JESD retry 0
    07:03:50:157 MYKONOS_readRxFramerStatus()

    07:03:50:157 MYKONOS_readOrxFramerStatus()

    07:03:50:158 MYKONOS_readDeframerStatus()

    07:03:50:158 cpp:_jesdStatus:764: AD9731 TX DeFramer Status: 0x28

    About 2% of the time, we see the Framer status of 0x7e. The software reconfigures the Mykonos JESD interface with the same routine but the error persists = 0x7e. 

    07:05:02:684 cpp:_jesdStatus:732: AD9731 RX Framer Status: 0x7e
    07:05:02:684 cpp:_decodeFramerStatus:3002: Framer lane FIFO read/write pointer delta has changed
    Framer has received the SYSREF and has retimed its LMFC
    ILAS State: ILAS Complete
    TX State: ADC Data
    07:05:02:684 cpp:_jesdLinkStatus:1550: AD9731 Mykonos JESD composite status false: Bad status read from RX Framer: 0x7e!
    07:05:02:684 AD9731 Mykonos JESD interface status invalid after initialization, re-trying
    07:05:02:684 MYKONOS_enableSysrefToRxFramer()

    07:05:02:684 MYKONOS_enableSysrefToObsRxFramer()

    07:05:02:684 MYKONOS_enableSysrefToDeframer()

    07:05:02:684 MYKONOS_resetDeframer()

    07:05:02:684 MYKONOS_enableSysrefToDeframer()

    07:05:02:785 cpp:_jesdLinkStatus:1539: JESD retry 0
    07:05:02:885 MYKONOS_readRxFramerStatus()

    07:05:02:885 cpp:_jesdStatus:732: AD9731 RX Framer Status: 0x7e


    If the Frame error bit 6 of 0x7e does not clear but the Deframer side is good, what do we know about the Rx Framer link? If the pointer is realigned, is the link functional?

    I am trying to determine the severity of the 0x7e status.

    Thanks again in advance.

  • There is a dedicated SYSREF and DCLK to each device.

    Are you generating all the clocks from single device including SysRef ?

    Can you send the setup Diagram including clock source  FPGA  device clock SysRef and DCLK signals ?

    Are the configured parameters same on both the sides (FPGA & Transceiver side )?

  • We are using an AD9528 to generate all the DCLK and SysRef signals. There is a dedicated output of the AD9528 for each of those signals. There are also two more dedicated signals for DCLK and SysRef to the FPGA. The Mykonos is on the same board as the AD9528. That board mounts to the main board, where the FPGA resides, using an FMC connector. The Tx Deframer parameters are the same as the corresponding FPGA core. The Rx Framer parameters are the same as the corresponding FPGA core. However, the Tx and Rx paths are not configured the same way, due to the application.

  • I was not clear but there are dedicated outputs from the AD9528 to the Mykonos as well as dedicated outputs from the AD9528 to the FPGA.

Reply Children
  • What is your SYSREF mode? Is it continuous SYSREF or single shot  ?

    Can you try with single shot SYSREF and let us know your observations?

  • All the devices are configured for a continuous SYSREF. I need to work with the software developers to change this and they are working on other projects.

    Have you seen success with doing this on other designs?

    It seems to me that the Mykonos needed three SYSREF signals to start up the JESD link. Is that correct? If so, then do we need to issue three single SYSREF pulses to bring up the link?

    I appreciate your help.

  • Is it reasonable/possible to leave the AD9528 continuously generating the SYSREF signal and have the Mykonos and FPGA in the single shot mode? Do you see any issues with that?

  • You can do that, but you need to ensure that there are SYSREF pulses reaching at the input of AD9371 after enable MCS.  

    The typical sequence for multichip synchronization is as follows:
    1. Initialize all devices in system using MYKONOS_initialize().
    2. Run MYKONOS_enableMultichipSync with enableMcs = 1
    3. Send at least three SYSREF pulses.
    4. Run MYKONOS_enableMultichipSync with enableMcs = 0.
    5. Load ARM, run ARM cals and continue to active transmit/ receive/.

    Hope, a single AD9528 sends the DEV_CLK and the SYSREF to the chips  and that the series of three SYSREF pulses are synchronous to the device clock.

  • We are using continuous SYSREF mode. We have two independent JESD204B interfaces in the data path with the FPGA in the middle (DSP-to-FPGA and FPGA-to-Mykonos). We use continuous mode because those interfaces are configured/reconfigured independently and we cannot stop the SYSREF signals independently with the 9528.

  • This error code, refers to issues with deterministic latency on the Framer side. You can try by sweeping the LMFC offset for the Framer and then check if you are able to get off with the issue.