AFE7950: 4T4R2F 8b10b 2.500 Gbps SERDES, 500 MHz REFCLK, PLL reporting not locked

I have made a bit of progress on this issue, but I am still having difficulty getting the device to fully function.  Here are my steps and results so far:

1. I reduced the amplitude of REFCLK to around 1Vpp differential swing and now the primary PLL locks indicated by the SPI read log:
   

   Writing into  0x0066 value  0x00
   Writing into  0x0066 value  0x01
   Writing into  0x0066 value  0x03
   Writing into  0x0063 value  0x41
   Writing into  0x0063 value  0x01
   Reading From  0x0066 value  0x33
   Reading From  0x0066 value  0x33
   Reading From  0x0066 value  0x33
   Reading From  0x0066 value  0x33
   Reading From  0x0066 value  0x33
   

   
   

2. We notice in our generated SPI log that the device is reporting that it’s SERDES PLL is not locked:
   any read from 0x0118,0x0119:
   

   Reading From  0x0119 value  0xff
   Reading From  0x0118 value  0xc0
   

   
   

3. What are all of the possible causes of the primary PLL achieving lock, but the SERDES PLL reporting out of lock?
   Do you see anything in the attached log that could point to a problem?
   

4. Note that this is a custom board, and we are not using Latte to configure the device.  We capture SPI transactions from Latte on our eval system and send them to the AFE7950 via custom SW after de-asserting RESET.

   We generate all clocks on our custom board:

   500 MHz AFE REFCLK
   3.90625 MHz SYSREF to AFE and FPGA
   156.25 MHz MGTREFCLK to FPGA
   

   • internal FPGA pll makes 31.25 MHz mgt_freerun_clock
   • internal FPGA pll makes 31.25 MHz tx_sys_clock
   • internal FPGA pll makes 250 MHz tx_sys_clock
   
   

   We have two boards that exhibit the exact same behavior.

   A note about our SW that drives SPI configuration of the AFE:

   • We noticed a few things by reviewing ./Documents/Texas Instruments/AFE79xxLatte/lib/AFE79xxConfig.txt
     • a. There are macros that are executed, and we are now checking whether the machine is ready for a macro and whether the macro successfully completed.  You may observe this in the attached log
     • b. There are burst writes that we believe we need to do as well.  We execute these bursts by writing each byte to an incrementing address
   • Can you tell me how to produce our own version of the AFE79xxConfig.txt logfile?  We are not seeing a new version generated upon each execution of Latte on our eval system, even though we think we are enabling logging by this command:

   logDumpInst=mLogDump.logDump(ASTERIX_DIR+DEVICES_DIR+r"\AFE79xxConfig.txt")

5. Please see the following attachments (zipped and attached):

   AFE79xxConfig.txt – I think this is an example and not generated by our Latte config

   2025-02-12.log - capture of SPI configuration of AFE7950 on our custom board

   setup_500.00_ddc48_fb24_duc96_DB.py - Latte setup used on eval board to capture SPI config

   bringup_4R_2F_4T.py - Latte script to configure the AFE7950
   
   
   e2e_serdes_pll_not_locking.zip
   

One more thing to note:  We used wireshark to observe the burst write pattern produced by running the setup and bringup scripts in Latte with our eval board.  We then used those bytes to issue our transactions (non-burst, but incrementing address)

Hi Jesse,

Also, if you would like to break the burst write section to individual writes you can also add the following command to you Latte script. 

device.logClassInst.logCombinedBurstWrites=False

Regards,

David Chaparro 

Hi David,
I am now able to generate the logDump correctly, and i turned off bursts to ensure that we had the formula correct for splitting up the burst writes.  We will review that log now and see whether we have an incorrect config.
Jesse

Hi David,
We have completed an initial review of the logDump vs. our SPI commands to the AFE.  We believe that we have done the configuration correctly. I am attaching the logDump, our SPI log from our custom board, and would appreciate your review to see if you notice anything that looks misconfigured.

Is there any signal needed externally (besides power rails, RESETZ, and REFCLK) needed to achieve SERDES PLL lock when external REFCLK is commanded as the source?

We noticed just a couple discrepancies between our SPI log and the SPI log from the Latte tool on the eval board:
1. I've already mentioned above that we read back 0x0118 and 0x0119 to indicate that the SERDES PLL is reporting unlocked and alarms
2. 

In the Digital Top Page:

Register 0x086b:
- Eval board: reads 0xd3
- Our board: read 0x57

Register 0x086a:
- Eval board: reads 0x00
- Our board: reads 0xc0

-----
Writing into  0x0011 value  0x00
Writing into  0x0015 value  0x40
Reading From  0x086b value  0x57
Reading From  0x086a value  0xc0
-----

logs.zip

Thank you,
Jesse

We used WireShark to capture all SPI transactions send by Latte to the eval board.  We will transition to using the logDump

Hi David,

I did a detailed review of the SPI log produced by our SW + custom board vs. the Latte logDump.  Both are attached in logs.zip above.  I would like it if you could review that material, and if you could specifically address the following areas in which I noticed a delta:
1. lines 20021-20035 of AFE79xxConfig_no_bursts.txt differs from our observed values in lines 16934-16935 of 2025-02-13T17_28_28-08_00_SPI.log when reading 0x012c and 0x0130.  We observe a value of 0xff and the eval system observes a value of 0x08.  The discrepancy appears to be in the ADC_JESD_AB page of the register map and indicate status of SYSREF and JESD_CLK.  Could you please tell me how to interpret those values?

2. Am I correctly interpreting the logfile in that reads from 0x0119 and 0x0118 indicate that our SERDES PLL is unlocked?  Could you list the dependencies that must be present for the SERDES PLL to lock?

Thank you,

Jesse

Additional questions:
1. We would like to select the primary PLL output as the source to the SERDES PLLs and adjust the divider settings to divide by 48 rather than 2.  Could you please provide the method to achieve this?  (shown in orange)

2. Is there a more recent copy of AFE79xx Programming User Guide available?  We are using a version marked Draft from May 2020.  The reason I ask is that the logDump contains bits set in some registers that are not listed in the User Guide.  For example: SERDES PLL 0x49fb is set to 0x72 which includes setting bit 1 which is not listed in the UG.

Thank you,
Jesse

Hi Jesse,

The GUI will automatically setup the clocking so it is not possible to manually change this. The Programming User Guide only describes the most common register used after device configuration so it will not have every register. We recommend following the log generated by the AFE79xx GUI.

For the clock issue we suspect this is related to the incoming clock. Did you have any chance to debug the amplitude issue at the input of the AFE? Are you able to share information on the clocking chip you are using and can you confirm that the AFE input clock is AC coupled? 

Regards,

David Chaparro 

Hi David,

We did adjust our input REFCLK to match the datasheet requirements, and attempted to match the measured the AFE7950EVM REFCLK levels as closely as was possible.  REFCLK is AC coupled.  That REFCLK adjustment alone did allow the primary PLL to lock, but the SERDES PLL remained unlocked.

We just recently performed a test where we routed the AFE7950 EVM SPI bus through our FPGA to allow Latte to directly interface with the AFE7950 on our custom module.  That test resulted in the expected bringup of the AFE7950 with the SERDES PLL reporting locked.  We have captured the SPI transactions and compared them to our prior method.  The only detected difference is that Latte performs burst transactions via SPI and our FW currently does not allow burst transactions. We noticed that even with this flag:  device.logClassInst.logCombinedBurstWrites=False , Latte still performs burst writes, but logs the bursts as individual bytes with incrementing address.  We then used an FTDI board to configure the AFE without burst transactions with success.  One thing we noticed while attempting an external connection to our FTDI board was that SPIB1 and SPB2 seem to not respond to read requests.  Is there a configuration that we need to do via SPIA in order to use SPIB1 and SPIB2?

Thank you,
Jesse