Forum Discussion

CHebl's avatar
CHebl
Icon for New Contributor rankNew Contributor
6 years ago

JESD204 IP-Core occasionally receives wrong data in internal loopback mode

I'm currently trying to implement the JESD204-IP Core to receive data from an ADC on an Arria 10 using Quartus Prime v18.1. To test the receiver I implemented both channels (TX and RX) of the Transceiver and manually switch into loopback mode. After initializing the link I transmit a ramp, which almost works fine. Occasionally and not reproducable the data in the receiver is wrong, even though the transmit word is correct.

Notice, that the transmitter in the following picture first transmits the value 0x58FF, and after that the value 0x5900:

The receiver instead first receives the 0x58FF (31 cycles later), but after that it receives a 0x5959, which is wrong. As you can see no errors are being asserted.

I'm currently using Subclass 0 with 2 lanes enabled and 2.5 Gbps transfer rate.

Does anyone have an idea, why this happens?

5 Replies

  • Nathan_R_Intel's avatar
    Nathan_R_Intel
    Icon for Contributor rankContributor
    6 years ago

    Hie,

    Apologies for the delayed first response. Since you mentioned there is no errors being asserted, this could be a signal tap sampling capture error. However to be certain, could you double check if the 8B10B decode errors are asserted. If yes, then this could be mean the incoming data is corrupted; suggesting intermitently something happens either at the channel level or device level to corrupt the data.

    If no, then this could mean the signaltap capture on the Rx side is incorrect. Please check for timing errors related to signaltap path or use a 2xfater sampling clock on signaltap.

    Regards,

    Nathan

  • CHebl's avatar
    CHebl
    Icon for New Contributor rankNew Contributor
    6 years ago

    Hi Nathan,

    many thanks for your answer.

    I've tried oversampling the output data, but the wrong received words are stable. I've also been using the CDR clock for sampling the data and wouldn't expect timing issues there, but the result was the same.

    I've also checked the code_err signals in the RX 8b10b block and those aren't being asserted either.

    I'm a little bit at a loss here.

    Best regards,

    Chris

  • Nathan_R_Intel's avatar
    Nathan_R_Intel
    Icon for Contributor rankContributor
    6 years ago

    Chris,

    Since there is no Rx 8B10B decode error, then there is more confidence that the received data is correct. Hence, this should be a Signaltap capture error. Could you describe how you oversampled the output data? My suggestion was to use a clock that is twice the speed of the recovered clock as sampling clock of Signaltap.

    Regards,

    Nathan

  • CHebl's avatar
    CHebl
    Icon for New Contributor rankNew Contributor
    6 years ago

    Hi Nathan,

    sorry for coming back to you this late.

    I configured the PLL, that's generating the link clock (I switched the RX Link Clock from CDR to PLL clock), to produce another clock at twice the frequency and used it to sample the data with a pipelining factor of 1.

    Another point I noticed is, that all the wrong received words have in common, that the byte patterns are repeated eg. 0x5959, 0x0202, 0x0303 etc.

    Furthermore its the most significant 8 bit, that are being duplicated to the least significant 8 bit (N=16). This is something I observe on the interface between my datapath and the IP-Core, so it isn't due to data reordering on my part (imo).

    This problem also occurs when using an external ADC from Analog Devices, so i believe the problem to be in the recieve path.

    Regards,

    Chris

  • Nathan_R_Intel's avatar
    Nathan_R_Intel
    Icon for Contributor rankContributor
    6 years ago

    Hie Chris,

    I tend to agree with you, your observation could be caused by something in the receive path. However, the data integrity should be good as long as no 8B10B error (as I mentioned previously).

    Can you attach your simplified design achieve (.qar) containing the JESD IP configuration with a connection to a black box (without your design) so , I could understand your design configuration to advice further whats going wrong.

    Regards,

    Nathan