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.

ADC12J1600: Incorrect captured data by JESD204B core

Part Number: ADC12J1600
Other Parts Discussed in Thread: TEST

Hi all,

I'm trying to develop an algorithm on FPGA to process the sampled data by the ADC. We're using TI's ADC12J1600 and Xilinx's KC705, also TI's TSW14J10 for connecting the two boards.

Here's the configuration of the ADC:

Decimation = 4;

LMFS = 4222;

K = 16;

Reference Clock = 200Mhz;

Device Clock = 100Mhz;

Here's the output data format:

Picture1.png

Picture2.png

I've created a 4-lane JESD204B RX project based on Xilinx's JESD204 Hardware Demo and JESD204 Example Design, here's the schematic:

Picture3.png

The configuration of the RX core is matched to the set up of the ADC. I chose to include the shared logic in the core considering we have only one RX core in our project.

By using the VIO, we can correctly perform the register read/write access. Here's the AXI Control Register configuration:

0   => x"8008",    -- Addr x008            

1   => x"0000",    -- Data x0000_0001       Enable Lane Alignment

2   => x"0001",   

3   => x"800C",    -- Addr x00C            

4   => x"0000",    -- Data x0000_0001       [0] Enable Scrambling

5   => x"0001",

6   => x"8020",    -- Addr x020            

7   => x"0000",    -- Data x0000_0001       F (octets per frame) = 2

8   => x"0001",

9   => x"8024",    -- Addr x024            

10  => x"0000",    -- Data x0000_000F       K (Frames per multi) = 16

11  => x"000F",

I'm using GPIO LEDs to check the interface signal, here's the results:

LED[4] is blinking, showing the FPGA can receive the reference clock and global clock;

LED[3] is on, showing the system clock is locked, and generating 200MHz clock for AXI Controller;

LED[2] is on, showing the JESD204B receiver can generate RX_aresetn signal, which serves as the reset signal for data demapping block;

LED[1] is on, showing the tx_resync is asserted, which is sent out to ADC;

LED[0] is on, showing the rx_resync is asserted, which is the synchronizing signal generated by the receiver;

The data is captured by the ILA, we have set the ADC to Ramp test mode and normal, here's the result:

(1) Ramp test mode -- each lane transmits an identical octet stream that increments from 0x00 to 0xFF and repeats.

Picture4.png

The data from 4 lanes are exactly the same, which is reasonable since the ADC is sending identical octet-stream to each lane. However, the value of the captured data is incorrect for now.

(2) Normal mode – a sine wave from the function generator is sampled by the ADC.

Picture5.png

The data we collect after the transport layer mapping is incorrect. However, the results of signal RX_start_of_frame, RX_end_of_frame, RX_start_of_multiframe, RX_end_of_multiframe comply with the simulation results from the JESD204 example design.

I think the JESD204 IP core is operating in the right way, so my guess about the cause of the error is I didn't correctly map the rx_data[127:0], here's what I did based on the output data format of the ADC:

//lane 0
signal0_sampl1 <= rx_tdata[31:17];        //data bits of every second sample on lane0
signal0_cntrl1 <= rx_tdata[16];                //control bit of every second sample on lane0
signal0_sampl0 <= rx_tdata[15:1];          //data bits of every first sample on lane0
signal0_cntrl0 <= rx_tdata[0];                  //control bit of every first sample on lane0
//lane 1
signal1_sampl1 <= rx_tdata[63:49];        //data bits of every second sample on lane1
signal1_cntrl1 <= rx_tdata[48];                //control bit of every second sample on lane1
signal1_sampl0 <= rx_tdata[47:33];        //data bits of every first sample on lane1
signal1_cntrl0 <= rx_tdata[32];                //control bit of every first sample on lane1
//lane 2
signal2_sampl1 <= rx_tdata[95:81];        //data bits of every second sample on lane2
signal2_cntrl1 <= rx_tdata[80];                //control bit of every second sample on lane2
signal2_sampl0 <= rx_tdata[79:65];        //data bits of every first sample on lane2
signal2_cntrl0 <= rx_tdata[64];                //control bit of every first sample on lane2
//lane 3
signal3_sampl1 <= rx_tdata[127:113];    //data bits of every second sample on lane3
signal3_cntrl1 <= rx_tdata[112];              //control bit of every second sample on lane3
signal3_sampl0 <= rx_tdata[111:97];      //data bits of every first sample on lane3
signal3_cntrl0 <= rx_tdata[96];               //control bit of every first sample on lane3

Any help with the configuration and/or how I have to use my IQ samples from rx_data to get the original data of Ramp or Sinewave would be great.

Thanks in advance.

Best,

Haotian

  • A supplement to the post is I set the NCO frequency to 0. Because instead of doing this, I got attenuation of the signal on HSDC Pro. And I set the frequency of the sinewave from the function generator to 2Mhz. Since I set the ADC in the decimation of 4, the sampling frequency is 400Mhz.

  • Do not set the NCO frequency to 0. This is an invalid setting.

  • Hi Jim,

    Thanks for your reply. I'm thinking that since there's the modulation of original data to generate I/Q data, I assume a demodulation block on FPGA is necessary to get the sampled data. Do you have any experience or suggestions on that?

    Thanks in advance,

    Haotian.

  • Haotian,

    I don't have much experience with this but it does sound correct.

    Regards,

    Jim

  • Jim,

    Thanks for your reply. Could you please share me with an instruction about how to set up ADC12J1600 working in bypass mode? I still want to test the JESD in Ramp test mode. I think we can set Fs = 1GSPS. And since there's no decimation, DDC block will not work so I don't need to care about NCO freq, right?

    We're using KC705, I know there're only 4 lanes on KC705 and the serial link configuration of bypass mode is LMF = 888. But since in Ramp test mode, the ADC is sending identical data to each lane, I think I can still test if my jesd-rx core on FPGA can capture the original data for these 4 lanes without considering the I/Q modulation. Do you think such an idea can be viable?

    Thanks so much for being so helpful to me, I really appreciate it.

    Best,

    Haotian.

  • Haotian,

    In box #3 of the ADC GUI, select "bypass Mode, DDR".

    Regards,

    Jim

  • Jim,

    I'm kinda confused about the output data format in decimation mode. The DDC output data consist of 15-bit complex data plus the two over-range threshold-detection control bits, how would this single over-range threshold-detection control bit affect the interpretation of the data's value?

    Another question is, as you can see from the two pics, does the channel 1 and channel 2 here separately represents I data and Q data?

    Best,

    Haotian.

  • Also, I want to ask about the ramp test mode. In ADC12J1600's datasheet, it's mentioned that "the transport layer is disabled and the input from the formatter is ignored. After the ILA sequence, each lane transmits an identical octet-stream that increments from 0x00 to 0xFF and repeats". Does it mean no matter I set the ADC in decimation mode or bypass mode,  it makes no difference in output data format? 

    Please take a look at my first post in this thread. In the ramp test mode, we can receive the same bitstream from each lane, but the value is not correct. 

    I think passing the ramp test mode is a very important step to validate the function of the JESD-RX core on the FPGA.

    The deadline for this project is urgent, could you please give some advice to my problems, or is it possible to make a reference to some other TI experts for me?

    I cannot say how much thankful I am to you, Jim. I understand your schedule must be busy, but I appreciate any help from you.

    Best,

    Haotian. 

  • Haotian,

    The ramp mode does not work in bypass mode. See last slide of attached file for what to expect.

    Regards,

    Jim

    6888.ADC12J1600_DEC_4_KC705_test_pattern_mode.pptx

  • Hi Jim

    I'm still testing the JESD by using the Ramp test mode, I start to get meaningful data:

    This is the best result I can get for now. I get this by disabling the scrambler of both TX in the ADC and RX in the FPGA. The weird thing is, the data is not increasing from LSB to MSB but decreasing, also you can see the noise in the plot.

    My question is, first, is the DDC block disabled in Ramp test mode? Or should I say, if the transmitter is directly sending the data to the lanes?

    Secondly, is the SYSREF signal provided by the ADC? I thought the SYSREF signal is coupled with the device clock from the ADC, but I'm not sure about it now.

    Just for your information, I see the SYNC signal is asserted by checking the GPIO LED.

    Best,

    Haotian.

  • Haotian,

    FYI,

    The reason the decimate mode ramp looks good and not the bypass mode is that it has to do with what the ramp pattern outputs, and how that aligns with the expected data word widths. The ramp pattern is always an octet ramp. It is not a ramp at the JMODE selected output data word width. Within each lane the octets increase:

    0, 1, 2, 3, 4, 5, ….., 254, 255, 0, 1, 2, 3, 4, etc.

     

    Since the DDC mode has a 16-bit word width, the octet ramp aligns within that and gives a reasonable looking ramp waveform when decoded as 16 bit words.

     

    The bypass mode has a 12-bit word width. The octet ramp values therefore do very strange things when decoded as 12-bit words.

    Regards,

    Jim

  • Hi Jim,

    I understand what you're saying about why the Ramp test is not proper for the bypass mode because of the mismatch of data width. So I still set the ADC in decimated by 4 and get that result from the FPGA.

    It seems to me there's periodical data corruption during the transition. Besides, the serial data seems to somehow get inverted. Can you see what might be the cause of these errors and how should I fix it?

    Another question is, I'd like to try to set up the JESD204B in subclass 0. I know how to configure the RX core on the FPGA from my project, could you tell me how should I configure the TX in the ADC?

    Best,

    Haotian.

  • Haotian,

    This device only supports subclass 1 mode. We invert all of the serde lanes going into the KC705 with our firmware as the P/N are swapped coming out of the ADC board. 

    Regards,

    Jim

  • Hi Jim,

    Thanks for your notification of inverting the serdes lane. That's will not be a big problem, I can fix that.

    Do you have any idea about how should I deal with the noise or the data corruption?

    Best,

    Haotian.

  • Haotian,

    Using Chipscope and a ramp test pattern, I would think this should be a relatively easy task to figure out. If not, consult with Xilinx. The issue is not with the ADC.

    Regards,

    Jim

  • Hi Jim,

    I just tried the

    long transport test pattern:

    Here's my result:

    I got no disparity error here, but the value of "gt_rxcharisk" is changing, I don't understand what that means.
    As for the data, rx_tdata[31:0] represents the data from lane 0, rx_tdata[63:32] represents the data from lane 1, etc. it seems to me that the lower octet and upper octet in each frame got swapped during the transition, is that correct?
    Another error I got is, instead of receiving 03 in lane 0 and 05 in lane 1, what I got is 1c and 1a. 
    I think these two problems together caused the error to my Ramp test.
    Could you think of anything regarding the problems I mentioned above?
    Sorry to ask you again, I feel like I'm close to getting this worked but I'm stuck by some details I cannot think of.
    Thanks for your continuous help during the past few months. 
    Best,
    Haotian.
  • Haotian,

    Lane 2 and 3 look correct in your capture. The data is read from right to left, with the most significant bit as the LSB, not left to right. See attached document. There may be a mistake in the data sheet regarding the 3 and 5 you are not seeing. I will look into this. otherwise, I think everything looks fine. 

    Jim 

  • Haotian,

    Regarding the charisk issue:

    "You will see Charisk get set because of Alignment Monitoring Characters being inserted into the data when the last octet in the frame or multi-frame is the same as it was the previous multi-frame. See section 5.3.3.4 of the JESD204B-01 specification. The behavior is slightly different depending if scrambling is on or off.  Try turning scrambling on for both ends of the link to see if that changes what they see.

    Regards,

    Jim

  • Hi Jim,

    Thanks for your reply.

    I tried turning on the scrambler on both TX and RX side, and the captured data got completely messed up, here's the result:

    Here's a closer look of my captured ramp data:

    Starting with the data under the first mark, I think the correct value should be 8f8e8d8c, so I wrongly got 3 octets. Similarly, the correct value of the next data should be 93929190, still, 3 errors here, etc. 

    Another apparent mistake is, by checking the data under the second mark. The octet should increase to a3a2a1a0, but somehow, my captured data jumped to 5c424140.

    These problems are so weird to me since I got no disparity error and the SYNC is asserted. It seems there's something wrong during the encoding/decoding process.

    Any help or advice from you would be highly appreciated.

    Looking forward to your reply.

    Best,

    Haotian.

  • Haotian,

    We do not have the bandwidth to support you with this effort now. I would suggest you start using the Xilinx help forum on their website or read up on the JESD IP Core document provided by Xilinx (see attached).

    Regards,

    Jim

     pg066-jesd204_v7.1.pdf

  • Haotian,

    One last thing that just came in regarding your issues:

    The lanes are inverted. 8b/10b encoding almost works correctly when lanes are inverted, but some codes don’t map correctly. This is what causes the 001A and 001C values to occur.  For example, 03 changes to 1C because their 10-bit representations are inverses of each other.  Many other codes map correctly when the data is inverted (02, 04, 00, 80, etc).  This becomes obvious when you look at a full 8b/10b mapping table for all codes.

     

    I don’t think the octet ordering is being swapped accidentally. It’s probably just the convention of this IP/FPGA to put the octets that were received first into the rightmost position of each 32-bit word.  So you have to read the four octet values from right to left.  For example,  01_80_00_80 was transmitted over the lane in this left-to-right time order: 80_00_80_01. 

    Regards,

    Jim

  • Hi Jim,

    My design is working now!!!

    The problem is the RXPolarity, and the errors are gone once I set it to 1'b1.

    I wanna send you my deepest gratitude, thanks for your continuous help during the past 3 months. And thanks for pointing out the most crucial problem in my design although it's not in your bandwidth.

    I wish you all the best in the future. (You must be already pretty annoyed by my nonstopping stupid questions...)

    Best regards,

    Haotian.