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.

ADC32RF45: Problem with ADC32RF45 Ramp Pattern in Bypass Mode

Part Number: ADC32RF45
Other Parts Discussed in Thread: ADC32RF80

Good day,

We are currenly designing a JESD204B receiver core on a Virtex-7 FPGA that recovers data from an ADC32RF45 clocked at 2.8 GHz.

The ADC is configured in DDC bypass mode and is set to produce a ramp pattern.
We are able to receive data of the CGS and ILA stages succesfully, but the data provided afterwards is not as expected.
Even though there is a consistent pattern in the data, it is not a ramp pattern.

This is the configuration information that we are writing to the JESD Digital Page.
0x4002, 0x00
0x4003, 0x00
0x4004, 0x69
0x7002, 0x0F
0x6002, 0x0F
0x7037, 0x01
0x6037, 0x01
0x7001, 0x80
0x6001, 0x80
0x7007, 0x0F
0x6007, 0x0F
0x7003, 0x01
0x6003, 0x01
0x7032, 0x3C
0x6032, 0x3C
0x7033, 0x3C
0x6033, 0x3C
0x7034, 0x3C
0x6034, 0x3C
0x7035, 0x3C
0x6035, 0x3C
0x7036, 0x40
0x703C, 0x01

As I understand this configuration info should allow us to configure the ADC to be in DDC bypass mode and to produce a ramp pattern. I assume the reason for our problem is that we are not configuring other registers correctly.

Does TI provide a complete configuration file for setting up the ADC32RF45 to produce a RAMP pattern in DDC bypass mode?

Kind regards,
Francois Tolmie

  • Francois,

    We are looking into this.

    Regards,

    Jim

  • Francois,

    There may be a typo in the data sheet. Please make the following changes to your settings:


    0x7002, 0x01
    0x6002, 0x01
    0x7037, 0x00
    0x6037, 0x00

    Remove 0x703C, 0x01 as this is not a valid address.

    Regards,

    Jim

  • Good day Jim,

    When writing
    "0x7002, 0x01
    0x6002, 0x01
    0x7037, 0x00
    0x6037, 0x00"
    the ADC's output resolution is configured to 14 bits.
    We need to configure the output resolution to 12 bits (LMFS = 82820). That is why I have:
    "0x7002, 0x0F
    0x6002, 0x0F
    0x7037, 0x01
    0x6037, 0x01"

    Is there something else that may cause the issue?

    As mentioned, we are able to receive data of the CGS and ILA stages succesfully.
    Thus, it seems like the JESD204B receiver is working correctly.

    Kind regards,
    Francois
  • Francois,

    The attached file generates a proper ramp on our setup in 12 bit mode (82820). The config file is attached for you to compare to your settings.

    Regards,

    Jim

    12bit_ramp_82820_mode.cfg

  • Good day Jim,

    Thank you for the file.

    We have used the configuration information that you provided, but the problem persists.

    The reasons why we do not think that the problem lies at the JESD204B receiver is because:
      - The D21.5 (high-frequency jitter pattern) test pattern works
      - The K28.5 (mixed-frequency jitter pattern) test pattern works
      - The Repeat initial lane alignment test pattern works
      - The data received from the 12-octet RPAT jitter pattern is consistent
      - ILA and CGS phases pass sucessfully
      - Even though the data of the ramp pattern does not seem correct, there is consistency among the data. I have attached a file to explain what I mean.

    Also, we have used the configuration information that you provided, but we had to alter it to suit our hardware configuration. We use single-ended control of SYNCB using the GPIO4 pin. Thus, we need to write 0x40 to registers 0x036 in the JESD204B digital page for both channels. We also need write 0x01 to registers 03Ch in the JESD204B digital page for both channels. The strange thing is that these (03Ch) are not valid registers in the ADC32RF45. These register are valid in the ADC32RF80, and does need to be set (along with registers 036h in the JESD digital page) to enable single-ended sync. Has this problem been experienced in the past?

    The device markings are as follows:
    AZ32RF45
    TI        714
    ZLH9   G4

    I would appreciate it if you could look at the recovered ADC data in the attached file.

    Kind regards,
    Francois

    File:

    Recovered ADC Data.txt

  • Francois,

    I have never tried the CMOS SYNC option. I am checking with the design team regarding register 03C. As far as you can tell though, you have a valid link with this, correct? Is the signal staying high when sending the ramp pattern? Have you tried the toggle pattern or custom pattern options?

    There are actually two ramps available. If you set register 0x37 to 0x4, then set address 0x3A to 0x02 (in decimation filter page), you will enable another ramp that changes count by 1 after 16 samples.

    With the ramp set using address 0x0x3 data 0x01 in page 0x6900, when looking at our captured ramp data, the samples should increment by a count of 1. You are not showing any sign of this. Is this data captured from signal tap (Altera) or Chipscope (Xilinx)?

    Regards,

    Jim

  • Francois,

    It has been confirmed by the design team that this mode is supported in ADC32RF45 as well, and the same writes (mentioned in ADC32RF80 datasheet) have to be followed to enable CMOS sync. Looks like this info was missed on the last update of the ADC32RF45 datasheet.

    Regards,

    Jim

  • Good day Jim,

    Thank you for your assistance and the configuration file that you provided.

    By using this configuration file I could ensure that the ADC32RF45 was configured correctly. This made it much easier to track down the source of the problem on the JESD204B receiver side.

    Also, thank you for the quick responses, I greatly appreciate it.

    Kind regards,

    Francois