This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADC12DJ3200EVM: wrong RX data

Part Number: ADC12DJ3200EVM

Hi

My system connfiguration is:

5 GSPS, JMODE 0

Linerate 10 Gbps, refclk 500 MHz, core:clk 250 MHz, no scrambler, K=4, I changed RX ¨polarity for DB0-DB3 lanes

I tested system by Ramp mode and it looks OK.

I also tried K28.5 mode, it also looks OK:

But in normal mode, i think that i get a wrong data on rx, actually I have no input signal (offset is set to 20 mV):

what may be wrong?

  • Hi Tomas
    Which capture platform are you using? Is this based on FPGA firmware provided by TI, or firmware you have developed independently based on the FPGA vendor JESD204B IP?
    Best regards,
    Jim B
  • Jim
    thanks for fast response. I am using Digilent board. For physical layer I use JESD204PHY from Xilinx, for other layers JESD204 I use FW from our company (colleagues use it with slower ADCs TI without problems). I set ADC for K=4, I have also problem to find charasters for end of frame in RX data from PHY layer.
  • Hi Tomas

    I reviewed your results further. I see in all ADC data and test modes you are getting character alignment, but there is no frame alignment. If frame alignment was working the ramp pattern would show up identically in all lanes after being realigned by the JESD204B elastic buffers.

    In the real data output mode, I do see the periodic 0 showing up for the 4 tail bits at the end of each frame, but these are not aligned across the lanes. Further analysis of the real data does show data near mid-scale but with some offset.

    Looking at gt2_rx, I see 30 occuring in the second full data group. Starting from the next data output I get the following:

    9429449419429410

    Grouping into 12bit values gives 942h, 944h, 941h, 942h, 941h followed by 0 for the 4 tail bits. These hex values correspond to around 2370 decimal. Nominal values with terminated inputs  and no offset would be around 2047d so there is some offset present.

    Other lanes with hex data displayed look similar, so I think once you resolve the frame alignment issue things should work OK.

    Note that with the scrambling turned off, the repeating tail bits at the end of frames and multi-frames will trigger the JESD204B alignment character insertion. The inserted alignment K characters may cause problems if you don't have a fully compliant JESD204B receiver IP designed to handle these characters.

    Turning scrambling on will reduce the occurrence rate of alignment characters, but they will still show up.

    Best regards,

    Jim B