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.

ADC16DX370: Questions about JESD Link Behavior

Part Number: ADC16DX370
Other Parts Discussed in Thread: LMK04828,

Dear Supporters,

Our application is a custom integration of FMC144 with Arria A10 SoC Development Kit. There is no reference design.

We have implemented a rudimentary JESD receiver communicating with the pair of ADC16DX370s.

The 2 ADC16DX370 chips on FMC144 are configured with the default register settings. CLKIN is generated by LMK04828 at 148.5MHz.

In this bring-up test configuration, FMC144 input A2 (VINA on the 2nd ADC16DX370) is driven by a 3.3V CMOS square wave at 14.85MHz.

This SignalTap capture shows the expected behavior immediately following completion of the ILAS:

However, even though SYNCb remains high, ADC16DX370 behaves as though the link has broken around sample 930, repeatedly sending BCBC followed by foreshortened ILAS:

The link eventually is re-established, for example after sample 7936:

Unfortunately, the link breaks intermittently thereafter. Here is the final example from this SignalTap capture (after which the link remains stable for more than 2000 samples, to the end of the capture):

My questions about this behavior are

Q1: Why would ADC16DX370 behave as though the link has broken under these circumstances?

Q2: Will the link remain stable after some point, so long as SYNCb remains unasserted by the receiver?

I have further questions about the assertion of the datak bit, which identifies a byte as a control character.

This capture highlights the character FC sent during ILAS is correctly identified as a data byte:

However, this capture highlights bytes received by the FPGA which should be data bytes but for which datak happens to be asserted:

Q3: Is this the expected behavior of the datak bit?

Q4: Can the JESD receiver safely ignore the datak bit?

Hopeful thanks in advance for your answers --todd

  • Hi Todd,

    I am looking into your questions further, and will get back with you soon.

    Can you please share a schematic of the ADC and how it is being clocked? Is SYSREF coming from the same LMK04828? Have you tried this same exercise on the other ADC's input?

    In regard to your first issue (questions 1 and 2), if the link is disturbed after a successful ILA, it could be due to LMFC misalignment with respect to a detected SYSREF pulse. Can you please explain how you are providing SYSREF to the ADC?

    I would also recommend looking at section 9.1.4 of the ADC16DX370 data sheet for more information on JESD Link interruptions.

    Best Regards,

    Dan

  • Hello Dan,

    Thank you for promptly responding with these diagnostic questions.

    Yes, SYSREF is coming from a single LMK04828, as per this schematic (Figure 18 from the Abaco FMC144 manual):

    Good suggestion to try the same exercise on the other ADC chip. This SignalTap capture shows that this ADC chip behaves as expected following SYSREF: It completes the ILAS just once, then starts sending data:

    The first trace in the SignalTap capture shows that SYSREF (driven from LMK SDCLKout1) pulses twice before being disabled.

    Given that the LMK's SDCLKout7 is programmed the same as SDCLKout5 and DCLKout6 the same as DCLKout4, and the two ADC chips are programmed identically, what might account for the fact that ADC chip #1 performs as expected but ADC chip #2 seems to suffer from LMFC misalignment?

    Hopeful thanks for your further comments on the above, and hopefully for your answers to my questions 3 and 4 from the original post on this thread.

    Thanks again for helping me --todd

  • Hi Todd,

    Have you been able to confirm that the SYSREF for the ADC chip #2 is toggling the same as the SYSREF for ADC chip #1. Are there settings that the FMC144 need to be aligned to as per the user document? Since the FMC144 board is not a TI product itself, this question might be better addressed in parallel with Abaco support since they may already be aware of this issue, or can help with a product that may be defective.

    In regard to your questions 3 and 4, these k characters are synchronization characters, and are a part of normal operation.

    Best Regards,

    Dan

  • Hi Dan,

    Thank you for getting back to me.

    I have not been able to observe the SYSREF pulse train with a scope, so I'm relying on SignalTap and SPI readback to observe the ADC16DX370 chips.

    The controller writes JESD_STATUS register 0x006C [6:0] with 8'h18 prior to arming the SYSREF detection gate.

    The LMK then provides a 2-pulse SYSREF train.

    After disarming the SYSREF detection gate, JESD_STATUS reads back 8'h7F. 

    Is this the expected value?

    The fact that ADC chip #1 is behaving perfectly, while ADC chip #2 is not, even though they are programmed the same, suggests that there may be an electrical issue; I will follow up with Abaco once I've eliminated possible logical issues.

    Thank you for this support --todd

  • Hello again Dan,

    I have been able to confirm with a second instance of the FMC144 in the exact same HW/SW setup that both ADC16DX370 chips respond correctly to SYSREF. Therefore, there is no issue with ADC chip programming, and there must be an electrical issue on the first FMC144. 

    You can go ahead and close this ticket.

    Thank you for your support.

    Sincerely --todd