• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 247 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ADC12DJ3200: ADC12DJ3200 RX_SYNC is not stable

liu chuang
Prodigy 50 points
Part Number: ADC12DJ3200
Other Parts Discussed in Thread: LMK04828, LMX2594

Board architecture：three ADC12DJ3200+one XILINX FPGA（7V690T）

ADC MODE:Single mode

ADC Sample rate：6G @ JMODE2

GTH Line rate：12GHz

FPGA CLK Frequence：300MHz

FPGA GTH BANK CLK:300MHz

sysref CLK Frequence：9.375MHz

When adc input signal is a broadband signal continuously,the rx_sync signal is stable.When adc input signal is a discontinuous broadband signal，the rx_sync signal is not stable.What is the difference between these two input signals for adc?

Note: When the input signal is a single frequency（Such as: 700mhz ）, the sync signal is also stable.

  • 0
    Prodigy 50 points

    Supplementary note: When the sync signal appears "0", test the ADC's power supply and sysref clock, and they are all normal.

    Continuous broadband signal range: 1.3GHz-2.3GHz (sync signal is stable)

    Intermittent broadband signal range: 1.4GHz-1.5GHz (sync signal is unstable), send the signal once every 200us；

    ADC input single frequency (generated by signal source): sync signal is stable；

    The rx_sync signal is captured by the FPGA's 204b IP core；

    Clock architecture: LMK04828(PLL1+PLL2)+LMX2594, external input clock frequency is 300MHz, LMK04828 outputs 300MHz signal to LMX2594, LMX2594 generates 3GHz to ADC, clock lock signal is normal.

  • 0 in reply to liu chuang
    TI__Mastermind 20541 points

    Hi,

    The behavior described above is rather odd. Input signal's frequency should not affect the JESD link. One think I would like you to try is reduce the sampling frequency by half sample and see if your link is more stable at lower serdes rate.

    Second thing to try is disabling the SYSREF to the ADC and try capture without running the SYSREF to the ADC.

    Regards,

    Neeraj

  • 0 in reply to Neeraj Gill
    Prodigy 50 points

    Thank you very much for your reply.

    I don’t think there is a problem with SYSREF CLK, because there is a DAC chip (AD9176) on the board. ADC and DAC share SYSREF CLK. The broadband signal (1.4GHz-1.5GHz) mentioned above is generated by the DAC chip. The DAC has always been is normal.

    There are three boards in total, two of which function normally. The last problem is the problem mentioned above.

    The soft is divided into two versions: 3G sampling rate (dual channel) and 6G sampling rate (single channel). The sampling rate of 3G works normally. The clock design of 3G and 6G sampling rate is completely the same.

  • 0 in reply to liu chuang
    TI__Mastermind 20541 points

    Hi, 

    Can you please monitor the alarm bits by reading the register 0x2c1 and see which alarm bit is getting set when you lose link. Please note you will need to Write a ‘1’ to each alarm bit to clear them. and read them to see the status. 

    This will give us some insight into what is causing the link to fail. 

    Regards,

    Neeraj 

  • 0 in reply to Neeraj Gill
    Prodigy 50 points

    Hi，

    The instability of the SYNC signal happens all the time.

    1. After configuring all registers, we cleared register 0x2c1 (write 1F)

    2. After the sync signal is pulled low, read the register 0x2c1 again, and the value is 00.

    3. After the sync signal is pulled low again, read register 0x2c1 for the second time, the value is still 00

  • 0 in reply to liu chuang
    TI__Mastermind 20541 points

    Hi,

    I forgot to mention that you will have to unmask the alarm bits by writing the value of 0x00 to register address 0x2C2. Once the bits have been unmasked you can then read the ALARM status register mentioned in previous post.  

    Neeraj Gill said:
    Can you please monitor the alarm bits by reading the register 0x2c1 and see which alarm bit is getting set when you lose link. Please note you will need to Write a ‘1’ to each alarm bit to clear them. and read them to see the status. 

    Can you please let me know the results of Alarm status register. 

    Regards,

    Neeraj

  • 0 in reply to Neeraj Gill
    Prodigy 50 points

    Hi

    1.We added a step, write 0x00 to register 0x2c2，and cleared register 0x2c1 (write 1F)

    2.After the sync signal is pulled low, read the register 0x2c1 again, and the value is 00.

    3. After the sync signal is pulled low again, read register 0x2c1 for the second time, the value is still 00

    The value of register 0x2c1 is always 0x00，Is the sync signal generated unilaterally by FPGA?

  • 0 in reply to liu chuang
    TI__Mastermind 20541 points

    Hi liu,

    The sync signal is controlled by the FPGA. If there is an issue with a link the FPGA will signal the ADC by pulling SYNC signal low to reestablish the link. The stability of link is not depended the frequency range of analog input signal. it the link works with Continuous broadband signal range: 1.3GHz-2.3GHz, It should also work with Intermittent broadband signal range: 1.4GHz-1.5GHz (sync signal is unstable), send the signal once every 200us.

    Can you make sure amplitude of intermittent broadband signal is not too high for the ADC?

    Regards,

    Neeraj

  • 0 in reply to Neeraj Gill
    Prodigy 50 points

    Hi

    We use a spectrum analyzer to test the amplitude of the DAC, -10dB~0dB.By looking at the ADC data sheet, this is also within the acceptable range of the ADC.

    Supplementary note: RX_SYNC signal comes from FPGA 204B IP core

    Looking forward to your reply.

  • 0 in reply to liu chuang
    TI__Mastermind 20541 points

    Hi Liu,

    Is the FPGA 204B ip core getting reset somehow when you are sending the Intermittent broadband signal range: 1.4GHz-1.5GHz? Can you look into that. 

    Regards,

    Neeraj