Post Go back to editing

Interfacing AD9082 JESD204C with Versal GTM

Category: Hardware
Product Number: AD9082

I am trying bring up a JESD204C link between a MxFE AD9082 and Xilinx Versal GTM transceivers. The GTM transceivers don't have the built in 64b66b ASYNC gearbox. Are there any example designs using ADI's JESD HDL IP interfacing with Xilinx Versal GTMs using JESD204C?

Thread Notes

  • Hi, I don't see GTM transceiver in our list of supported ones, but I'll check our plan and get back to you. 

  • Hi, AMD doesn't make any dev kits which route GTM to the FMC connector, therefore it is not supported as we cannot test it. If the GTM doesn't have 64B/66B then probably only 8B10B encoding of JESD204C would be supported. Any reason you want to use GTM instead of GTY? 

  • Thanks for the Quick reply. I am using a third party Versal VP1502 development board with the AD9082 Eval board and the only GTs routed to FMCs are the GTMs.

  • Sorry to hear of the trouble. I suppose you will have to implement JESD TRX with GTM yourself. Let us know if you need any assistance from us.

  • I have been working on this for a while and tried connecting jesd204_versal_gt_adapter to Xilinx's gt_soft_helper block, which has an implementation of a 64B66B encoder/decoder. I then connected the gt_soft_helper to the GTM lane data. This got the link up, but I was seeing that all of the CRC-12's were failing. I just realized that their block was putting the header after the data instead of before. So, I tried putting the 2-bit header and 62 bits of the data into gt_soft_helper's data port and the last two bits of data into the header port. This seems to have fixed my CRC-12.

    I am now also able to verify that Data layer PN7 sequence passes on the FPGA->DAC link. Both the MxFE and FPGA report that the link is up; however, on the MxFE side I am occasionally seeing the MxFE report LANE_FIFO_EMPTY reading MxFE register 0x5AE. The bits are mostly not set; however, if I keep on reading the register, I see random lanes report LANE_FIFO_EMPTY. Is it normal to see LANE_FIFO_EMPTY and still have a PN sequence pass?

    I am running in DAC JESD204C mode 18. The DAC sample rate is 12GHz and coarse interpolation is 2. So, I am running 8 lanes with a lane rate of 24.75Gb. Both the MxFE and FPGA are getting 375MHz from the HMC7044 on the Evaluation board. The MxFE ADC is running in full bandwidth mode at 6GHz and JESD204C mode 19.

    I am using ADI's IIO linux drivers to bring up the link.

    The JESD status utility reports:

    And the MxFE status reports that the link is good:

    If it wasn't for me seeing the LANE_FIFO IRQ being set, I would think that the link is up and Okay. Do you have any ideas why I am seeing the LANE_FIFO flag be set? Is this normal?

  • Hi, thank you for sharing your works and data. It sounds like that there is no bit error with PN7 on data layer while you see LANE_FIFO_EMPTY flag is set randomly. I'll check with the team what is expected in this case. Could you clarify how often roughly this flag is set?

  • Yes it seems like the PN7 sequence passes on the data layer going to the DAC. I have run that test for 60 seconds and it passes with no errors. I wrote a script to read register 0x05AE 1000 times back-to-back which takes about 2 seconds to complete. About 30% of the time it reports that a lane FIFO is empty.

  • Hi, the fifo_full and fifo_empty flags don’t necessarily mean data is being missed but they are more of a warning of potential dangers (more like almost full or almost empty). I believe that the implication of these flags is that the FIFO is close to a timing violation and might have a little extra room to operate. It is possible that on the JRX side that the clock is wandering a little bit and on occasion the flag will trip but the FIFO will still pass data properly as long as that clock doesn’t walk too much. It is possible for the frequencies to be locked over a long period of time but their relative phase to wander. Could you try long term test for bit errors?

  • Thanks for the update! How long do you consider long term? I ran a test for 30 Minutes with no PRBS errors reported in the MxFE. Is there a way to improve the JRX clock wandering? Its concerning that the link might be on the edge of working and needing to run a PRBS test to check the link health.

  • You may want to try more stringent patterns such as PN31 or PN23 to build more confidence and 30 min test woudl be more meaningful with these patterns. Some amount of "clock wander" is not uncommon, and you should feel pretty confident with PN31 overnight test. Hope this helps.