Forum Discussion

ONors's avatar
ONors
Icon for New Contributor rankNew Contributor
4 years ago

JESD204B debug

I have a custom board which uses JESD204B to receive samples from a ADC. I have two such boards. On one of them JESD204B works as expected, on the other it does not. On the board that is not working I see in reg 0x64 rx_err1 of the JESD204B IP that csr_cg_sync_err, csr_unexpected_kchar, csr_not_in_table_err, csr_disparity_err and sometimes csr_ilas_err are set. I see that the IP de asserts sync. I use only one lane. I see no error regarding sysref. Nor do I see any error reported from the ADC. Does this indicate that the synchronization of the ADC and the FPGA failed because corrupted data was received? How can I proceed to debug the faulty board?

8 Replies

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    As I understand it, you are observing some problem with the JESD204B RX working with an ADC. Only one of the two boards is exhibiting this problem. The other board is working fine. I am assuming that both boards are the same and using the exact same FPGA design.


    Based on the current observation, it seems to be related to the signal integrity problem which lead to data received corruption. To further narrow down this, you can try to do the following:


    1. Use oscilloscope to probe as closest to the FPGA RX balls, check the eye diagram to see if can spot any anomaly.


    2. Repeat the same for the good board and compare the eye diagram with the faulty to see if can spot any anomaly.


    3. Check all the clocks on the faulty board to see if there is any anomaly.


    4. You can use signaltap to check PHY status signals to further narrow down the problem. You may refer to table "PHY Status Signals for All Supported Devices Except Intel Stratix 10 E-tile

    Devices" in the JESD204B IP user guide for the list of signals to monitor.


    Please let me know if there is any concern. Thank you.


    • ONors's avatar
      ONors
      Icon for New Contributor rankNew Contributor
      4 years ago

      Thank you for the suggestions.

      1. 2. Unfortunately I do not have the equipment to probe those high frequency signals.

      3. I have not been able to check the ADC clock, but the other clocks looks good.

      4. I did add those signals you suggested to signal tap and they all look good.

      Next I made the signal tap file as described under Creating a Signal Tap Debug File to Match Your Design Hierarchy. I am currently in the process of trying to find any difference between the working board and the failing board.

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    Thanks for your update. I understand about the challenge to probe the high speed eye diagram.


    Would you mind to share with me the signaltap that you capture in #4? I would like to take a look to see if can isolate out any block.


    Please feel free to keep me posted on your latest debugging findings. Thank you.



  • ONors's avatar
    ONors
    Icon for New Contributor rankNew Contributor
    4 years ago

    I put the ADC in a test mode where it sends a constant stream of K28.5 characters (0xBC). On the working board that is what I see received. On the failing board I see more or less garbage. At times it is mostly 0xBC, at other times it is mostly spam. Attached are exported vcd-files from signal tap.

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    Thanks for your update. Would you mind to share me the signaltap files? I am not familiar with analyzing the VCD files.


    One debug test that you can look into to further narrow down the problem location is creating a duplex JESD instance, enable the serial loopback, send data from TX to RX and see if RX is able to achieve link up. This could help to isolate if it is within FPGA or ADC related.


    Thank you.


  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    Thanks for sharing the signaltap. As I compare the failure signaltap with the "JESD204B Link Initialization" in the user guide, it seems like the rx_pcs_data_valid was not asserted after the reset_n is released. Without the data valid assertion, the subsequent link up event is not taking place. We can further narrow down our debugging to the PMA portion. Note that the SI is still an area of suspect.


    To facilitate further debugging on this, please do the following:


    1. Use signaltap to check the PHY status signals to further narrow down the problem to PMA. You may refer to table "PHY Status Signals for All Supported Devices Except Intel Stratix 10 E-tile Devices" in the JESD204B IP user guide for the list of signals to monitor if you are not using S10 E-Tile.


    2. Tap the signals in "PHY Status Signals for Intel Stratix 10 E-tile Devices" if you are using S10 E-Tile.


    3. What are the specific Quartus and FPGA part that you are using?


    4. Please try to look into the serial loopback test which I mentioned in my previous post.


    Please let me know if there is any concern. Thank you.


  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    As I understand it, it has been some time since I last heard from you. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.