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 Reply
  • Cpeters - no, we have not resolved this. We have tried several approaches but have not been able to eliminate this problem. We are just living with it for now. My next step is to see if the data integrity is impacted when we see 0x7E or if the error is a one-time issue and then the link is good. I am waiting for funding to do this. Sorry for the delayed response. 

  • Good timing.  Our FPGA engineer has actually made some progress on this.  We think we've been able to eliminate the 7E issue by a changing the timing of the write to MYKONOS_ADDR_SERIALIZER_SPECIAL.  This is normally called in mykonos.c in the function MYKONOS_setupSerializers().

    CMB_SPIWriteByte(device->spiSettings, MYKONOS_ADDR_SERIALIZER_SPECIAL, 0x03);
    We've changed that line to 
    CMB_SPIWriteByte(device->spiSettings, MYKONOS_ADDR_SERIALIZER_SPECIAL, 0);
    Then we added the setting of MYKONOS_ADDR_SERIALIZER_SPECIAL to 0x03 to our "headless" code implementation right before "Step 15" from the users guide.  Step 15 is "Send the SYSREF signal to bring up the JESD204B interface."
    Using this approach we've not seen the 0x7E issue in 1000's of tuning iterations. 
    Also, we've setup a PRBS loopback test and observed that the 7E issue, when it occurs does not seem to impact data integrity.
    We understand that updating Mykonos.c is not allowed by ADI, but since they could not seem to help, you gotta do what you gotta do.
  • cpeters - Thank you very much for your response. I will pass this on to our firmware engineer and ask him to implement it.

    I agree that "you gotta do what you gotta do." I miss the dedicated FAE days.

  • Please let us know how it goes.  We are still working on this, so I will update you if something changes.

  • Just waiting for SW to implement this change. Hopefully soon. 

  • cpeters - with the implemented change, our system testers ran 4 sets of tests with 100 iterations each and did not see this error. We very much appreciate your help.

  • Good to hear.  We've made some further progress on this issue. 

    We also moved the write to DESERIALIZER_SPECIAL out of mykonos.c.

    We were doing 3 Sys Ref Requests to the 9528 after the call to MYKONOS_enableMultichipSync now only doing 2.

    We also tweaked delays after resets to the various PLLs.

    We typically run 1000's of tunes and each time we tweaked something we got less and less errors.  Not sure we are at 100% success yet, but getting closer.