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.

ADC12J4000 JESD Short Pattern Test

Other Parts Discussed in Thread: ADC12J4000

Hi All,

I am trying to establish the JESD data link between FPGA and ADC12J4000 using evaluation boards (KCU105, TSW14J10EVM, and ADC12J400EVM).

I am using the [JESD204B TI Reference design] provided for TSW14J10EVM.

In Ramp test mode, I am able to see correct data on all lanes, but in Short Pattern test mode I notice something different than expected according to the ADC12J4000 datasheet. 

ADC is running at 4 GSPS in Bypass mode, with K set to 32, and scrambler turned off in both FPGA and ADC. Programming the ADC using GUI provided with EVM. I noticed the polarity inversion of JESD lanes on ADC12J400EVM and accounted for it in the FPGA. 

Any ideas what might be the cause of this discrepancy?

Thanks,

Ranjeet

This is what I observe:

Lane0:  0xFF0 0x021 0xFF0 0x043 0x0F0 T: 0x5

Lane1:  0xEE1 0x121 0xEE1 0x143 0x0E1 T: 0x5

Lane2:  0xDD2 0x221 0xDD2 0x243 0x0D2 T: 0x5

Lane3:  0xCC3 0x321 0xCC3 0x343 0x0C3 T: 0x5

Lane4:  0xBB4 0x421 0xBB4 0x443 0x0B4 T: 0x5

Lane5:  0x996 0x621 0x996 0x643 0x096 T: 0x5

Lane6:  0xAA5 0x521 0xAA5 0x543 0x0A5 T: 0x5

Lane7:  0x887 0x721 0x887 0x743 0x087 T: 0x5

 

According to the datasheet, this is the expected pattern:

Table 37. Short Transport Test Pattern

LANE (CONVERTER ID)

SAMPLE NUMBER (SID)

 

S0

S1

S2

S3

S4

0

0xF01

0xF02

0xF03

0xF04

0xF05

1

0xE11

0xE12

0xE13

0xE14

0xE15

2

0xD21

0xD22

0xD23

0xD24

0xD25

3

0xC31

0xC32

0xC33

0xC34

0xC35

4

0xB41

0xB42

0xB43

0xB44

0xB45

5

0xA51

0xA52

0xA53

0xA54

0xA55

6

0x961

0x962

0x963

0x964

0x965

7

0x871

0x872

0x873

0x874

0x875

 

Lane0:  0x50F0043FF0021FF0 0xFF0 0x021 0xFF0 0x043 0x0F0 T: 0x5
Lane1:  0x50E1143EE1121EE1 0xEE1 0x121 0xEE1 0x143 0x0E1 T: 0x5
Lane2:  0x50D2243DD2221DD2 0xDD2 0x221 0xDD2 0x243 0x0D2 T: 0x5
Lane3:  0x50C3343CC3321CC3 0xCC3 0x321 0xCC3 0x343 0x0C3 T: 0x5
Lane4:  0x50B4443BB4421BB4 0xBB4 0x421 0xBB4 0x443 0x0B4 T: 0x5
Lane5:  0x5096643996621996 0x996 0x621 0x996 0x643 0x096 T: 0x5
Lane6:  0x50A5543AA5521AA5 0xAA5 0x521 0xAA5 0x543 0x0A5 T: 0x5
Lane7:  0x5087743887721887 0x887 0x721 0x887 0x743 0x087 T: 0x5
 
 
  • Hi Ranjeet

    I'm looking into this issue.

    Can you also provide a data capture showing the results when the Octet Ramp is enabled?

    Can you provide the snapshots from within the Xilinx development tool?

    Thanks,

    Jim B

  • Jim,

    Thanks for the quick response as always.

    While analyzing the results, I noticed that I might not be extracting the samples from the data stream correctly (MSB vs LSB justified), so let me look into that and I'll update the thread once I am certain.

    Thanks,
    Ranjeet
  • Jim,

    As it turns out, I was incorrectly extracting the Samples from the Octet stream. As shown in the datasheet, the samples are MSB justified, but I had inadvertantly applied LSB justified slicing.

    After I fixed that bug in my code, I am now able to see observe the pattern as expected.

    Thanks,

    Ranjeet

    Observed now:

    Lane0:  0x50F0043FF0021FF0 0xF01 0xF02 0xF03 0xF04 0xF05 T: 0x0

    Lane1:  0x50E1143EE1121EE1 0xE11 0xE12 0xE13 0xE14 0xE15 T: 0x0

    Lane2:  0x50D2243DD2221DD2 0xD21 0xD22 0xD23 0xD24 0xD25 T: 0x0

    Lane3:  0x50C3343CC3321CC3 0xC31 0xC32 0xC33 0xC34 0xC35 T: 0x0

    Lane4:  0x50B4443BB4421BB4 0xB41 0xB42 0xB43 0xB44 0xB45 T: 0x0

    Lane5:  0x5096643996621996 0x961 0x962 0x963 0x964 0x965 T: 0x0

    Lane6:  0x50A5543AA5521AA5 0xA51 0xA52 0xA53 0xA54 0xA55 T: 0x0

    Lane7:  0x5087743887721887 0x871 0x872 0x873 0x874 0x875 T: 0x0