AD9371 Framer lane FIFO read/write pointer delta has changed

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

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.

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

Thanks

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.

Mike4fpgas said:

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:958MYKONOS_enableSysrefToObsRxFramer()

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.

Mike4fpgas said:

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.