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.

ADC12J4000EVM: Test Pattern samples ordering issue

Part Number: ADC12J4000EVM
Other Parts Discussed in Thread: ADC12J4000

Hello,

we have bought an ADC12J4000 EVM and are currently working with Xilinx VC707 firmware (TI_HSDC_Pro_Reference_design_V2.8), as a base for our own development of a simpler firmware.


Our current task is interpreting the data received from our ADC Platform, and, while implementing my own firmware, we noticed a perplexing behaviour regarding the ordering of each sample.


To test it out, we have set up the Ad converter to transmit in TEST PATTERN MODE and watch the results (as in SLAS989D, table 33, page 48).

In the attached image we have the rx_tdata (input to the data_block of the sample firmware) and the test pattern data as in your manual.

We Expected a certain behaviour, but:

- we recognized that each half byte is inverted

- we recognized that bytes are inverted in couples

- what we are missing is the correspondence of the byte which should be the LSB of samples number 16-17-18-19-20-21-22-23 as in the table 13 of the aforementioned SLAS989D document.


What are the bytes in red colour actually representing?


Are we extrapolating the data in the wrong position?

  • Hi Michele
    I want to back up a few steps to understand how you are getting from the received data for each lane (8 lanes total), to the data in the image shown above.
    Can you provide the ChipScope probe screenshot for the data from each individual lane covering at least 2 full frames of data?
    The data from the deserializer blocks is output in 32-bit (4 octet) blocks. The problems I have encountered in the past are related to mapping the data from those 32-bit blocks into 12-bit samples in the proper order.
    The 32-bit blocks are organized with the earliest octet at the right, and later octets moving to the left. So each 32-bit block needs to be processed from right to left, then the next later 32-bit block is processed, etc.
    It might also be useful to look at the same data using the JESD204B Test Pattern Mode - Ramp Test Mode. In this test mode each lane outputs a ramp in the octet data. All lanes start simultaneously at 00 and ramp up to FF then repeat the pattern.
    Best regards,
    Jim B
  • "The problems I have encountered in the past are related to mapping the data from those 32-bit blocks into 12-bit samples in the proper order."


    Yep, I also think there is some issue about it. To map the data from the 32 bit sub-parts of the 256 bit rx_tdata lane, we are using the Table13 (since we are in BYPASS MODE), ordering like this:

    - bits from 0 to 11: sample 0

    - bits from 12 to 23: sample 8

    - bits from 24 to 31: LSBs of Sample 16

    - bits from 32 to 43: sample 1

    - bits from 44 to 55: sample 9

    - bits from 56 to 63: LSBs of sample 17

    [And so on for the 8 lanes and the total of 256 bit]

    ...and at the following clock cycle, our FSM interprets the data starting with:

    - bits from 0 to 3: MSBs of sample 16

    - bits from 4 to 15: sample 24

    - bits from 16 to 27: sample 32

    - bits from 28 to 31: tailbits, which should be ignored (but we don't get zeros in the correct places here!)

    I will test with the ramp and report also.

    Regarding your question, I hope I have explained our process indirectly, but I will try again (sorry, English is not my native Language, hope I'm doing fine)

    At the moment what we are doing is the following:

    - we start from the rx_tdata[255:0] coming out of the JESD_RX block

    - we save the data as in original firmware inside 8 different FIFOs, split into subsections of 32 bits each (0:31 - 32:63 - etc) (standalone tested, works as intended)

    - after we have saved a certain window (for example 8192 samples at the present time), we activate a flag and communicate to initiate a FIFO read (standalone tested, works as intended)

    - we save oneoutput of each of the FIFOs in 8x32-bit (shift) registers (standalone tested, works as intended)

    - we reconstruct the ordered sample data as explained before, by applying shifts to the original 32 bit data, 12 bit at a time, and treating properly the "middle samples" which are split into two "subsections" (standalone tested, works as intended)

    - we read the serialized output data, hoping to find a sin wave when we have a sin wave at the input (does not work)

    thanks

  • Hello,

    I tested the jesd RAMP mode

    then separated each lane (0:31 - 32:63) and so on in the system ILA (chipscope heir) window

    The ramp seems to work correctly.

    attached you can find the image

  • I am currently testing the SHORT TRANSPORT PATTERN TEST MODE.

    The data I see is either wrong or hard to interpret.

    I attach the image of the first two 32-bit samples (the first image is the second "half" frame, i cannot switch the order apparently!), because they do not correspond to what I am expecting.

      

  • Hi Michele

    Looking at the Short Transport Test Pattern images, I believe the data is correct.

    Starting with the second image (1st half of frame) we have:

    F0021FF0

    Re-arranging the octet values starting with the right-most octet:

    F0 1F 02 F0

    Re-grouping into 12-bit values gives:

    F01 F02 F0

    Similarly processing the data from the other image (2nd half of frame) we have:

    50F0043F

    Re-arranging from right-most octet:

    3F 04 F0 50

    Adding it all together in 12-bit values

    F01 F02 F03 F04 F05 0 (last 4 are Tail bits)

    The other lanes look correct using the same approach.

    If you look at the frame groups in the ramp data they are arranged similarly. Increasing in value from right to left within each half-frame.

    I hope this is helpful.

    Best regards,

    Jim B

  • Hello Jim,
    and thanks for the thorough explanation. It is clear and I am applying it to my firmware.

    So, imagine if i would want to operate on the samples coming from the A/D converter, for some additional elaborations (ex. a FFT).

    If my firmware reads the samples (let's imagine we want to FFT the short transport test pattern, even if it makes no sense) in such order:

    F01 - E11 - D21 - C31 - B41 - A51 - 961 - 871 - F02 - E12 and so on...

    ...is this the CORRECT procedure of reading?

    Thanks again!
  • Hi Michele
    Yes, that is the correct sample ordering.
    Best regards,
    Jim B
  • Hello Jim,

    by applying the detection /" decription" scheme you have suggested, I am able to read the short transport test pattern correctly, and serialize the samples as I have indicated in my previous reply.

    How come that I cannot obtain the correct behaviour when I have a signal generator with a -5 dBm SinWave at 200 MHz in input of the A/D converter?


    The attached image refers to such application:

      (between markers are the 8 + 8 samples which ruin the sinusoid data)

    It seems like the samples in S0 column and in the S2 column (referred to the same scheme you provided) are EXCHANGED. But they work as expected when part of the Short Transport Test Pattern.


    Thanks in advance.


    EDIT:


    i assigned the bits of the S0 "column"  i.e. [31:24,15:12] to S2 and the bits of S2 "column" i.e. [7:0,39:36] {where 39:36 means bits 7:4 of the following clock cycle, i saved the two 32bit strings into 64 bit registers}

    and this is what I obtain:

    A perfectly reasonable sinwave.

    ...but ... why?

  • Hi Michele
    I'm not sure why making that change helped.
    To confirm this is a real solution try changing the frequency of the input signal so it is slightly different, maybe 190 MHz. That will cause the sine-wave to not be synchronous to the sample frames and help determine where the ordering problems are occurring.
    Regards,
    Jim B
  • Hello Jim and thanks for the suggestion.


    I have tried a frequency for 188 MHz so it is a worst divideable number, yet the behaviour after applying our bit switch seems to be extremely correct.

    I have now applied a FFT module to this reconstructed sin-wave and it is recognized the correct f_0 frequency bin, even at 188 MHz.

  • Hi Michele
    That looks good. I'm glad you've got it working OK.
    Best regards,
    Jim B