The TI E2E™ design support forums will undergo maintenance from July 11 to July 13. If you need design support during this time, open a new support request with our customer support center.

AFE7950: Clocking and SYSREF architecture to achieve deterministic latency JESD204B subclass 1

Part Number: AFE7950

Tool/software:

Hi David,

Related to my prior post:

I’d like you to review our planned re-spin to achieve deterministic latency in our system.  We are using a single AFE7950 device connected via JESD to a single FPGA.  We plan for the following parameters:

AFE7950 REFCLK     : 12 GHz (sample clock direct source from PLL)

FPGA GTREFCLK      : 156.25 MHz (sourced by external PLL)

SYSREF             : 3.90625 MHz

SERDES             : 2.5 Gbaud

tx_sys_clock       : 31.25 MHz (sourced by external PLL)

FsDAC=120000 MS/s  Interp by 96

FsADC=3000 MS/s    Dec by 48

FsFbADC=3000 MS/s  Dec by 24

8 active SERDES lanes Tx & Rx

JESD204B subclass 1 signaling

We reviewed recommendations in: https://www.ti.com/lit/ml/slap159/slap159.pdf

Our system appears to be working fine with our initial spin, but we have not done extensive testing on deterministic latency.  Based on your recommendation in https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1460074/afe7950-4t4r2f-8b10b-2-4576-gbps-serdes-jesd-link-not-always-initializing-properly/5675986?tisearch=e2e-sitesearch&keymatch=%2520user%253A635474#5675986 , we are removing the PLL internal to the FPGA that previously generated the 31.25 MHz tx_sys_clock signal and replacing it with an externally generated 31.25 MHz clock which is phase-locked to the GTREFCLK and REFCLK signals.  Note:  Our PLL is our design and not an LMK device.

We plan to align each SYSREF signal to its related clock falling edge in order to meet timing at the receiving device (not to scale, but representative of relative timing):

We plan to length match REFCLK to AFE_SYSREF (group1), and length match GTREFCLK to FPGA_SYSREF (group2).  We do not plan length match group1 to group2.  We do not plan to length match the 156.25 MHz clock to the 250 MHz or 31.25 MHz clocks.

 

Please let me know if you see any issue with our achieving deterministic latency with the proposed configuration.

  • Hi Jesse,

    Is there a reason that you are using a different clocks for the Tx_sys_clock and rx_sys_clock? Also, please note that it is these clocks that are used to sample the SYSREF so i would recommend length matching the SYSREF with the sys_clk.

    Regards,

    David Chaparro 

  • Thank you, David.  I am using rx_sys_clock at 250 MHz which is 8x the lane data valid rate.  The reason I selected that higher rate clock is to optimize resources by processing the data with a clock at 8x the lane data rate.  This works out really well in my design and avoids an additional rate change FIFO.  Please note that the 250 MHz processing clock is phase-locked to the 31.25 MHz tx_sys_clock and 156.25 MHz MGTREFCLK.  What's the best way to proceed?