Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

ADC09QJ1300: TI204C-IP JESD FPGA IP interface

Part Number: ADC09QJ1300

Tool/software:

Hello,

I'm admittedly new to JESD204 interfaces, and trying to get a minimalistic design up and running with a single converter (ADC) while understanding what is required for evolution of the design later.

Part of my confusion is related to the relationships between the system clocks, SYNC, and the IP itself. Referring to https://www.ti.com/lit/ug/slau808/slau808.pdf?ts=1730067416711&ref_url=https%253A%252F%252Fwww.ti.com%252Ftool%252FADC09QJ1300EVM Section B.2 shows several valid clocking configurations:

B.2.1 "Ext CLK from LMK to ADC" (Default)

In this configuration both a device clock (DCLK) and Sysref (SDCLK) are sent to both devices. Sending the DCLK to the ADC makes sense as that sets the sampling rate, and the SDCLK provides a reference for synchronization.

i) The parts that I'm not clear with here are 1) Why is one of the DclkX signals sent to both FPGA_GBT_CLK[0] and FPGA_GBT_CLK[1]? 

ii) What frequency should the FPGA_GBT_CLK receive? The sampling rate?

iii) Should the FPGA_SYSREF signal be received on a global clock buffer?

iv) What is the purpose of the PLL_REFO --> FPGA_CLK connection here?

More generally, why must a DCLK be sent to the FPGA at all? The JESD204 physical layer embeds the clock, which is later recovered. Is it a valid operating configuration to send a DCLK to the ADC, and a SYSREF to both the ADC and the FPGA, using local clocking otherwise within the FPGA?

Thank you in advance.

  • Hello Aiden,

    The ADC09QJ1300 is a little more confusing as it has some more advanced clock features to ease system use. So first I will explain the basic clock requirements of the a JESD link. 

    The ADC will take one sampling clock operating at whatever your sample frequency is for example say 1.3 GHz, then based on the JESD mode the part is configured in the data will get packed in a certain way see 6-16. Depending on the mode the link rate will be different this can be calculated using the following equation FS*R = Linerate, where R is the number of bits transmitter per lane per ADC core sampling clock cycle, and is specified for each mode of operation in table 6-16.

    So for example for JMODE8 at Fs= 1.3 GHz the line rate will be 1.3 * 12.375 = 16.0875 Gbps. All of the other clock frequencies will be derived off this value...

    The first required reference clock is the GBT Clock, this clock is used as a reference clock to the FPGA XCVR quads so they can lock their PLLs to the correct line rate the ADC is generating. This value has a number of different available ranges depending on the FPGA you are using but typically it is an integer divisor of the lane rate. For most of our applications the GBT Clock is set to the same frequency as the SYS Clock provided to the FPGA. Which can be calculated as follows...

    The SYS Clock is a reference clock provided to the FPGA that must be on rx_data_width cycle. So it is based off of the rx_data_width on set on your FPGA, the encoding scheme you are using and the line rate. For most of our applications and for the TI JESD IP the rx_data_width is set to either 64 bits or 32 bits. So lets take 64 bits for example... The SYS Clock can be calculated as follows.

    Sys_Clock = linerate / (rx_data_width * encoding) for 8b10b it would be 10/8 and for 64b66b it would be 66/64. For rx_data_widths of 64 the dividers work out to be 80 for 8b10b and 66 for 64b66b. So for our JMODE8 example we would get the following sys clock frequency...

    Sys Clock = 16.0875 / (64 * 66/64) = 243.75 MHz, and as I mentioned before for simplicity sake we will set the GBT ref clock to this value as well.  

    Sysref is not a strictly required signal it is only required if your application has multiple converters that need synchronization or deterministic latency on the link. This clock frequency can be calculated by equation (7) and (9) depending on if you are operating in an 8b10b mode or 64b66b mode. 

    The SYS Clock signal must go to a global clock capable pin of the FPGA but the SYSREF signal does not have to.

    The ADC09Qj1300 also includes on chip PLL and VCO for taking in an external reference and generating the device sampling clock so no external clock generator chip is needed. The PLLREFO pin is used to output a copy of the reference clock provided to the ADCs PLL and in the block diagram you are seeing it is being used as the SYS clock to the FPGA.

    Hopefully this helps address your questions. Let me know if you have any additional concerns.

    Best,

    Eric

  • Thank you for taking the time to write the response Erik. This makes me believe that I had conflated Sys_Clock and a periodic SYSREF with one another!

    Based on your input I believe I need to change my clocking plans. In the interests of testing my own understanding and serving as a potential example to other users, would it be OK if I replied back to you or edited this post and DMd you later this week with a numeric plan for the various clocks based on the selected JMODE to see if I've understood?

  • Hi Aiden,

    Sure you can add onto this post, or create a new one if you like. Whatever is easiest for you.

    Best,

    Eric

  • Thanks once again for your help Eric,

    Here's my frequency plan to see if I've understood the guidelines you've provided.

    1) ADC sampling frequency. I've opted to generate this off-chip as it looks like this has a lower jitter than using the onboard PLL to do so which may have SNR implications. I have selected 983.04 MHz

    2) With 8 lanes and selecting JMODE0, I calculate a sysref frequency of 1.536 MHz (using a k of 4 and an n of 16) via the equations on page 61 of the ADC manual.

    3) Since R is 8 in this JMODE, I calculate a linerate of 7864.32 MHz

    4) For the GBTCLK I opt to divide the linerate by 32 to arrive at 245.76 MHz

    5) For the FPGA Sysclk I assume 64 bit reception width and given 8b10b encoding in JMODE0 I arrive at the linerate of 153.6 MHz

    My questions are

    1) Have I made any obvious errors?

    2) For the FPGA clocks (gigabit transceiver clock of 245.76 and sysclk of 153.6 MHz) which of these counts as the DCLK to which the JESD204 sysref signal is relative? I am assuming it's the gigabit transceiver clock, but want to confirm.

    2) Due to the Integrated Lane Alignment, I understand that I don't need to match the JESD traces between lanes to each other, but I believe I need to take care of the skew between the DCLK and the Sysref for both devices (I plan to use the clock generator IC to do so), but do I need to worry about any other relative delay matching? e.g. Sysclk to GBTclk delay?

    Thank you very much in advance and please let me know either way.

  • Hi Aiden,

    For JMODE0, Fs=983.04MHz then all the frequencies work out to be 

    linearte = 7864.32 Mbps

    sysref = 1.536 MHz

    GBT Ref Clock if divider is 32 is correct. One thing I will caution is you will need to check if this frequency is valid for your FPGA.

    SYSCLK divider = 64* 10/8 = 80 ... SYSCLK = 7864.32/80 = 98.304 MHz (this is different then what you calculate)

    So most of the clocks look good but the SYSCLK frequency was a little off.

    The SYSREF gets sampled by the SYS Clock not the GBT clock.

    The length matching between sysref between ADCs does not have to be very tight, there are functions on both ADCs that can align themselves to the SYSREF signal. The SYSREF to the FPGA does not have to be matched to the SYSREF to the ADCs and it does not have to be length matched to the SYSCLK to the FPGA. There is also no length match concern with GBTCLK to SYSCLK.

    Are you also planning on using the TIJESD IP on your FPGA or another JESD IP? And which FPGA are you targeting?

    Best,

    Eric

  • Thanks for the insight Eric!

    I've marked your answer as a solution.

    I'm planning to use the TIJESD IP, and we are targeting a Kintex Ultrascale+. We already have the IP but shortly after requesting it there was a pivot from an Artix target to a Kintex which among other things has changed the JMODE we want to operate in so I plan to submit a new request with the updated details.