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.

ADC08DJ3200: Trying getting erroneous test pattern out of jesd204b

Part Number: ADC08DJ3200

Running the chip at 6.4GHz, 16 Channels of data over JESD204 is working correctly and subclass 0 is running smoothly to a Xilinx MPSoC.  When I run test patterns from the ADC I get bad data on some channels.  Always the same bad channels.

Test pattern 4 or ramp i get errors that are code based.

instead of 0xB0 i get 0xAF

0x64 i get 0x7B

0x67 i get 0x78

Across all 16 channels.  I have not done an exhaustive search in this mapping.

Test pattern 5 or Short Transport Test Pattern 

0x03 => 0x1C

0x05 => 0x1A

0x06 => 0x19

0xFC => 0xE3

0xFA => 0xE5

0xF9 => 0xE6

And in this case it is isolated to 6 of the 16 lanes because of the nature of the test pattern.  This test is the same on both A group of 8 and B group of 8.

Am I not configured correctly?  I have double checked my polarity.

  • Hi Corey
    From your description it sounds like you are using JMODE=17 with Fclkj = 3200 MHz. Is that correct?
    Do you have scrambling enabled or disabled? If possible please provide the register values you are programming after the device is powered up.
    Best regards,
    Jim B
  • Scrambling is off, Jmode 17, @3.2GHz
    i write
    self.write(0x200, 0) # clear jesd_en
    self.write(0x061, 0) # clear cal_en
    self.write(0x201, 17) # jesd_mode JMODE
    self.write(0x202, 31) # KM1 or just K
    self.write(0x204, 0) # jctrl
    self.write(0x205, 0) # test mode 4 = ramp, 5 = increament, 0 = normal
    self.write(0x061, 1) # enable cal_en
    self.write(0x200, 1) # enable jesd_en
    self.write(0x06B, 0) # SOFT CAL OFF
    self.write(0x06B, 1) # SOFT CAL INIT
    I then check alarms @ 0x2c1 == 0x00 and status @ 0x208 == 0x64
  • Took enough data from test mode 4 to back out the new mapping.
    There is a 1 to 1 mapping with no overlap or gaps. Nothing is random.

    After looking at this table and comparing it to the 5b/6b table for 8b/10b encoding on wikipedia, whenever disparity is used to enocde (or decode!) the last 5 bits the polarity is flipped.

    I can fix this with a lookup table.  But Why is it doing it?!?

    Desired/True Output from ADC/Jesd204b
    0b00000000 0b00011111
    0b00000001 0b00011110
    0b00000010 0b00011101
    0b00000011 0b00000011
    0b00000100 0b00011011
    0b00000101 0b00000101
    0b00000110 0b00000110
    0b00000111 0b00011000
    0b00001000 0b00010111
    0b00001001 0b00001001
    0b00001010 0b00001010
    0b00001011 0b00001011
    0b00001100 0b00001100
    0b00001101 0b00001101
    0b00001110 0b00001110
    0b00001111 0b00010000
    0b00010000 0b00001111
    0b00010001 0b00010001
    0b00010010 0b00010010
    0b00010011 0b00010011
    0b00010100 0b00010100
    0b00010101 0b00010101
    0b00010110 0b00010110
    0b00010111 0b00001000
    0b00011000 0b00000111
    0b00011001 0b00011001
    0b00011010 0b00011010
    0b00011011 0b00000100
    0b00011100 0b00011100
    0b00011101 0b00000010
    0b00011110 0b00000001
    0b00011111 0b00000000
    0b00100000 0b00111111
    0b00100001 0b00111110
    0b00100010 0b00111101
    0b00100011 0b00100011
    0b00100100 0b00111011
    0b00100101 0b00100101
    0b00100110 0b00100110
    0b00100111 0b00111000
    0b00101000 0b00110111
    0b00101001 0b00101001
    0b00101010 0b00101010
    0b00101011 0b00101011
    0b00101100 0b00101100
    0b00101101 0b00101101
    0b00101110 0b00101110
    0b00101111 0b00110000
    0b00110000 0b00101111
    0b00110001 0b00110001
    0b00110010 0b00110010
    0b00110011 0b00110011
    0b00110100 0b00110100
    0b00110101 0b00110101
    0b00110110 0b00110110
    0b00110111 0b00101000
    0b00111000 0b00100111
    0b00111001 0b00111001
    0b00111010 0b00111010
    0b00111011 0b00100100
    0b00111100 0b00111100
    0b00111101 0b00100010
    0b00111110 0b00100001
    0b00111111 0b00100000
    0b01000000 0b01011111
    0b01000001 0b01011110
    0b01000010 0b01011101
    0b01000011 0b01000011
    0b01000100 0b01011011
    0b01000101 0b01000101
    0b01000110 0b01000110
    0b01000111 0b01011000
    0b01001000 0b01010111
    0b01001001 0b01001001
    0b01001010 0b01001010
    0b01001011 0b01001011
    0b01001100 0b01001100
    0b01001101 0b01001101
    0b01001110 0b01001110
    0b01001111 0b01010000
    0b01010000 0b01001111
    0b01010001 0b01010001
    0b01010010 0b01010010
    0b01010011 0b01010011
    0b01010100 0b01010100
    0b01010101 0b01010101
    0b01010110 0b01010110
    0b01010111 0b01001000
    0b01011000 0b01000111
    0b01011001 0b01011001
    0b01011010 0b01011010
    0b01011011 0b01000100
    0b01011100 0b01011100
    0b01011101 0b01000010
    0b01011110 0b01000001
    0b01011111 0b01000000
    0b01100000 0b01111111
    0b01100001 0b01111110
    0b01100010 0b01111101
    0b01100011 0b01100011
    0b01100100 0b01111011
    0b01100101 0b01100101
    0b01100110 0b01100110
    0b01100111 0b01111000
    0b01101000 0b01110111
    0b01101001 0b01101001
    0b01101010 0b01101010
    0b01101011 0b01101011
    0b01101100 0b01101100
    0b01101101 0b01101101
    0b01101110 0b01101110
    0b01101111 0b01110000
    0b01110000 0b01101111
    0b01110001 0b01110001
    0b01110010 0b01110010
    0b01110011 0b01110011
    0b01110100 0b01110100
    0b01110101 0b01110101
    0b01110110 0b01110110
    0b01110111 0b01101000
    0b01111000 0b01100111
    0b01111001 0b01111001
    0b01111010 0b01111010
    0b01111011 0b01100100
    0b01111100 0b01111100
    0b01111101 0b01100010
    0b01111110 0b01100001
    0b01111111 0b01100000
    0b10000000 0b10011111
    0b10000001 0b10011110
    0b10000010 0b10011101
    0b10000011 0b10000011
    0b10000100 0b10011011
    0b10000101 0b10000101
    0b10000110 0b10000110
    0b10000111 0b10011000
    0b10001000 0b10010111
    0b10001001 0b10001001
    0b10001010 0b10001010
    0b10001011 0b10001011
    0b10001100 0b10001100
    0b10001101 0b10001101
    0b10001110 0b10001110
    0b10001111 0b10010000
    0b10010000 0b10001111
    0b10010001 0b10010001
    0b10010010 0b10010010
    0b10010011 0b10010011
    0b10010100 0b10010100
    0b10010101 0b10010101
    0b10010110 0b10010110
    0b10010111 0b10001000
    0b10011000 0b10000111
    0b10011001 0b10011001
    0b10011010 0b10011010
    0b10011011 0b10000100
    0b10011100 0b10011100
    0b10011101 0b10000010
    0b10011110 0b10000001
    0b10011111 0b10000000
    0b10100000 0b10111111
    0b10100001 0b10111110
    0b10100010 0b10111101
    0b10100011 0b10100011
    0b10100100 0b10111011
    0b10100101 0b10100101
    0b10100110 0b10100110
    0b10100111 0b10111000
    0b10101000 0b10110111
    0b10101001 0b10101001
    0b10101010 0b10101010
    0b10101011 0b10101011
    0b10101100 0b10101100
    0b10101101 0b10101101
    0b10101110 0b10101110
    0b10101111 0b10110000
    0b10110000 0b10101111
    0b10110001 0b10110001
    0b10110010 0b10110010
    0b10110011 0b10110011
    0b10110100 0b10110100
    0b10110101 0b10110101
    0b10110110 0b10110110
    0b10110111 0b10101000
    0b10111000 0b10100111
    0b10111001 0b10111001
    0b10111010 0b10111010
    0b10111011 0b10100100
    0b10111100 0b10111100
    0b10111101 0b10100010
    0b10111110 0b10100001
    0b10111111 0b10100000
    0b11000000 0b11011111
    0b11000001 0b11011110
    0b11000010 0b11011101
    0b11000011 0b11000011
    0b11000100 0b11011011
    0b11000101 0b11000101
    0b11000110 0b11000110
    0b11000111 0b11011000
    0b11001000 0b11010111
    0b11001001 0b11001001
    0b11001010 0b11001010
    0b11001011 0b11001011
    0b11001100 0b11001100
    0b11001101 0b11001101
    0b11001110 0b11001110
    0b11001111 0b11010000
    0b11010000 0b11001111
    0b11010001 0b11010001
    0b11010010 0b11010010
    0b11010011 0b11010011
    0b11010100 0b11010100
    0b11010101 0b11010101
    0b11010110 0b11010110
    0b11010111 0b11001000
    0b11011000 0b11000111
    0b11011001 0b11011001
    0b11011010 0b11011010
    0b11011011 0b11000100
    0b11011100 0b11011100
    0b11011101 0b11000010
    0b11011110 0b11000001
    0b11011111 0b11000000
    0b11100000 0b11111111
    0b11100001 0b11111110
    0b11100010 0b11111101
    0b11100011 0b11100011
    0b11100100 0b11111011
    0b11100101 0b11100101
    0b11100110 0b11100110
    0b11100111 0b11111000
    0b11101000 0b11110111
    0b11101001 0b11101001
    0b11101010 0b11101010
    0b11101011 0b11101011
    0b11101100 0b11101100
    0b11101101 0b11101101
    0b11101110 0b11101110
    0b11101111 0b11110000
    0b11110000 0b11101111
    0b11110001 0b11110001
    0b11110010 0b11110010
    0b11110011 0b11110011
    0b11110100 0b11110100
    0b11110101 0b11110101
    0b11110110 0b11110110
    0b11110111 0b11101000
    0b11111000 0b11100111
    0b11111001 0b11111001
    0b11111010 0b11111010
    0b11111011 0b11100100
    0b11111100 0b11111100
    0b11111101 0b11100010
    0b11111110 0b11100001
    0b11111111 0b11100000

  • Hi Corey

    That behavior isn't due to the ADC itself. This has definitely been verified during design and validation of the device. I ran a quick test on an EVM today and captured the following data in JMODE17 with ramp test mode.

    ADC12DJ3200EVM_JMODE17_RampTest_Scr0_TDPlotExport.xlsx

    This format combines the data from all lanes in the standard sample order into a single column of decimal data. I have added a column to convert from decimal to binary.

    Are you using the standard Xilinx JESD204B IP?

    Best regards,

    Jim B

  • I am using the standard Xilinx jesd204b Ip from xilinx.  Nothing fancy.  I have poured over the jesd204b phy and jesd204b cores many times.  I cannot fathom any of these settings affecting the data in this way.

  • Hi Corey

    Thanks for the additional information. I'm working on additional theories and debug steps that can be tried.

    I did notice one item in your configuration sequence that should be changed:
    For the calibration step you have the following after the JESD204 link is enabled:
    self.write(0x06B, 0) # SOFT CAL OFF
    self.write(0x06B, 1) # SOFT CAL INIT

    Please change the writes to 0x06B to be similar writes to 0x06C. The value of 0x06B should be left at the default value of 0x00.
    Register 0x06C should be written to 0 then to 1 and left at 1 until the next calibration needs to be triggered.

    Best regards,
    Jim B
  • Hi Corey
    I was doing a little searching into similar issues to what you are seeing and found the following thread on the Xilinx support site. Please double check that Rx Equalization is set to LPM for all lanes.
    forums.xilinx.com/.../839416
    Let me know if you make any progress, I'll continue doing a little more research.
    Best regards,
    Jim B
  • I have double checked each of the 16 GTYs have great BER on the eye coming into the FPGA.  I will double check this.

    Corey

  • Hi Corey

    Do you have any updated information?

    I discussed the issue with a colleague and have the following items you can look into to help debug the problem:

    1. Does reducing the clock frequency and bit rate have any effect on the behavior? Since the bit rate is already only 4Gbps I think this won't do anything but if it is easy it is worth a try.
    2. Can you access/probe the 10b values before they are 8b10b decoded? That might be useful for analysis.
    3. Does the RX IP report any errors (disparity, not-in-table, etc.)?
    4. Can you capture the ILA information for each lane? Is it correct for all lanes, or is there a problem even in the ILA in the lanes that have the issue?

    Also, is this on a board of your own design, or using the ADC08DJ3200EVM?

    If it is your own design, is the MPSoC on the same board or is there a connector in between boards?

    Best regards,

    Jim B

  • Still the same problem.  I am LUTing all of the codes into their correct codes for now.

    1. Have not tried, but I would have to white wire the board to try this.

    2. I can, I will try this next.

    3. The IP is not reporting any errors.

    4.  All lanes have this issue.  All lanes are acting the same.

  • Hi Corey
    For item 4. Can you capture and share the ILA data for each lane?
    In your initial post you stated that in ramp mode you get incorrect data on all lanes, but for normal data and transport test mode only some lanes have issues. Can you capture ILA and some of the following data for Normal data mode, Ramp mode and Transport Pattern test mode?
    Can you enable scrambling in the ADC (SCR bit in JESD204B Control Register) and receiver IP? I would like to see if that improves or changes the behavior.
    Best regards,
    Jim B
  • So this issue has been resolved.  In all my testing I changed the bit file in my zynq mpsoc several times.  Reboot several times.  I had not power cycled the entire board including the Gigabit ADC for a week.  Upon power cycling the Gigabit ADC and Jesd204b cores worked as expected.  I am not sure if it was an errant command I have sent the ADC to behave this way or if it was the chip.  I will reopen this topic if the issue shows up again.

  • Hi Corey
    That's great news!
    In the future, to ensure something like this isn't caused by the ADC, add the following command followed by a very short delay to the start of the register programming sequence:

    self.write(0x000, B0) # soft reset of ADC
    'delay' # delay of 1 microsecond or more is sufficient
    write remaining register settings

    This will set all registers to default values, and reset state machines, etc. so you will be working from a known state.
    Let me know if you run into any more issues.
    Best regards,
    Jim B