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.

ADC14X250: JESD Link-Up status is not stable

Part Number: ADC14X250

Tool/software:

Hi,

I am working with the ADC14X250RHBT and using Xilinx JESD204C & JESD204 PHY IP in my FPGA RTL project. While programming the ADC chip registers, I’ve noticed intermittent behavior with the JESD link-up status. Sometimes, I achieve a link-up with the PLL locked and receive correct data, but other times the link does not establish.

After reviewing the register configurations, I believe they are valid for enabling communication between the FPGA and the chip. I’ve attached the register configuration file for reference. I observed that the JESD_STATUS register (0x006C) returns two different values: 0x1B, indicating the link is not up, and 0x6F, indicating the link is up and everything appears normal.

Currently, I receive data only when I see 0x6F in the JESD_STATUS register.

Input Frequency to ADC: 250 MHz

Sysref Frequency : 5 MHz (Integer multiple of LMFC clock)

k = 25;LMFC frequency = Fs/(k*s) = 250/(25*1) = 10 MHz 

Given the urgency, any suggestions or guidance would be greatly appreciated.

Thanks & Regards,
Sourav

adc_jesd_cfg.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
0x0000 : 0xbc
0x0002 : 0x1
0x0003 : 0x3 (Read-only)
0x0004 : 0x1 (Read-only)
0x0005 : 0x0 (Read-only)
0x0006 : 0x0 (Read-only)
0x000C : 0x51 (Read-only)
0x000D : 0x04 (Read-only)
0x0010 : 0x03
0x0012 : 0x85
0x0013 : 0x20
0x0014 : 0x0
0x003D : 0x0
0x0060 : 0x61
0x0061 : 0x0
0x0062 : 0x1
0x0063 : 0x0
0x006C : 0xFF (Write-first to clear the re-alignment bits)
0x006C : 0x1B/0x6F (Read the JESD_STAT)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi,

    Sometimes, I achieve a link-up with the PLL locked and receive correct data, but other times the link does not establish.

    Please advise if you observe this on the ADC or the Xilinx FPGA

    I observed that the JESD_STATUS register (0x006C) returns two different values: 0x1B, indicating the link is not up, and 0x6F, indicating the link is up and everything appears normal.

    Currently, I receive data only when I see 0x6F in the JESD_STATUS register.

    Will you be able to provide JESD204 error read out from your FPGA Xilinx IP? This will help us understand the error observed

    During the register 0x006C read back from the ADC14X250, if you are reading back 0x1B, this indicates PLL is unlocked as you had mentioned. 

    Can you perform a manual calibration to observe PLL status again afterwards?

    -Kang

  • Hi Kang,

    In response to your questions:

    1. I am observing the link-up/link-down status on the ADC side by reading the 0x006C status register.

    2. I will attempt manual calibration, but should I include a sufficient delay to allow the calibration to complete, considering it requires a certain number of Fs cycles (since I’m programming via TCL)?

    An important point I forgot to mention: on the FPGA side, I sometimes see SYNC toggling intermittently. During multiple power cycles, I’ve observed that SYNC remains stable in some cycles but toggles in others. Could this be causing the ADC to lose link stability, resulting in different values in the 0x006C register?

    I’ve verified that both the ADC clock and sysref are continuous and stable, so in theory, the PLL should lock every time.

    I’ve attached the JESD204 IP register dumps from my FPGA design, showing both cases: 1) when rx_sync is stable and 2) when rx_sync toggles.

    Please let me know if you want me to perform a few more experiments on it. I will get back to you as soon I complete the calibration experiment.

    Thanks & Regards,

    Sourav

    sync.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Sync without toggle(Data state) - Active high
    JESD204C IP Register Dump
    000: 04020D00
    004: 00000001
    020: 00000000
    024: 00000000
    028: 00000000
    030: 00000001
    034: 00000001
    038: 00000000
    03C: 00001801
    040: 00000001
    044: 00000000
    048: 00000000
    04C: 00000000
    050: 00000000
    054: 00000000
    058: 00000000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    nosync.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    #sync toggling(CGS State) - Active low
    JESD204C IP Register Dump
    000: 04020D00
    004: 00000001
    020: 00000000
    024: 00000000
    028: 00000000
    030: 00000001
    034: 00000001
    038: 00000000
    03C: 00001801
    040: 00000001
    044: 00000000
    048: 00000000
    04C: 00000000
    050: 00000000
    054: 00000000
    058: 00000004
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi

    Do you have any update on the above mentioned.

    Thanks

  • Hi,

    I performed manual calibration by switching between Normal and Power Down modes. I observed that in Power Down mode, reading the 0x06C register returns 0x10. Upon switching to Normal mode, I sometimes see 0x6F, and at other times 0x1B.

    I have a question about bit fields [3] and [4]. Before reading the status register (0x006C), I write 0xFF to it. Afterward, I observe either 0x6F or 0x1B when I read back. Is this approach correct? The documentation suggests that writing '1' will set bit [4] to 0, so I’m uncertain if my method is accurate.

    Additionally, I'm unclear about the purpose of the PLL. The ADC architecture doesn’t appear to have a PLL. I’m providing a 250 MHz sampling clock, which is detected and passes through a divider (which, in my case, is set to 1). However, since there’s no PLL in the diagram, I’m unsure why I occasionally observe PLL unlocks and re-alignments, which I believe might be causing the 0x1B status.

    Could you clarify the role of the PLL in this setup and any other possible reasons for the re-alignment?

    Thanks & Regards,

    Sourav