Post Go back to editing

AD9164 - Achieving Deterministic Latency

I am trying to obtain deterministic latency between the AD9164 and a Xilinx UltraScale+ FPGA using the Xilinx JESD204B core. I can establish a link between the devices and reliably transfer data, but the latency through the device changes from POR to POR. Note I am running both the DAC and Xilinx Core in Continuous sync mode. The JESD interface is configured as follows.

Data rate: 4.8GHz

Lane rate: 12GHz

PCLK rate: 300MHz

Frame rate: 1.2GHz

M=1

L = 8

F = 1

S = 4

I believe that my clock relationships are correct and that I am meeting the Setup/hold requirements for SYSREF but I cant see the clocks right at the part. I can only observe at the PLL generating both DCLK and SYSREF clocks.  Is there anyway to verify using registers inside the part?

To measure the latency through the interface, I have a data generator inside the FPGA that I am using to generate a 300MHz sine wave. Until enabled, the data generator outputs zeros and when enabled generates a 300MHz sine wave. The enable used to start the generator is output with the data and I am using it to measure the delay from the start of data transmission into the JESD transmitter until the data is output from the DAC. I am also reading the the SYSREF_PHASEx  and SYNC_LMFC_STATx registers with each transfer. These are the latencies I am seeing from POR to POR and the SYSREF_PHASE for each:

SYSREF PHASE         Delay

       0xF80                  156.2nS

       0xFC0                  160.0nS

       0xFC0                  136.8nS

       0xF80                   136.8nS

       0xF00                   136.8nS

       0xF80                   136.6nS

       0xF80                   139.8nS

       0xFE0                   137n

Parents
  • To eliminate the variability caused by SYSREF phase as reported by registers 0x037 and 0x038. I collected the POR-to-POR delays for a single SYSYREF phase. What I observed is that for any of the 4 SYSREF phases the POR-to-POR delays obtains are always one of eight values. Each is separated by 1 PCLK; the total delay span is equal to 8 PCLKs. Other than the 1 the  I am observing to a single sysref phase as reported by registers 0x038 and 0x037 what I found is that the POR-to-POR delays observed  fall into 8 distinct bins; each separated by 1 PCLK and the total delay span is 8 PCLKs. If I factor out the skew caused by the SYSREF phase, the delays are the same for all 4 possible SYSREF phases. It would appear as though a divide by 4 and a divide by 2 counter somewhere in the SERDES clock circurty is not being reset or the PLL is not locking up correctly. But the state of the PLL_STATUS register (0x281) indicates that the PLL is locked and all is well.

    If I leave LMFC_DELAY and LMFC_VAR registers (0x304 and 0x306) programmed to their reset states and monitor the DYN_LINK_LATENCY register (0x302) the value reported after each POR-to-POR it can be used to determine which of the 8 delays that will occur. Unfortunately it is only correct about 75% of the time. The other 25% the delay is off by 1 PCLK.

    It is interesting that there is significant correlation to the observed delays to both PCLK and LMFC_DELAY and this must all mean something. I could definitely use some help from Analog Devices to solve this issue.

  • hi, cebrady

    I also met the same problem. have u solved this issues ?

  • I was never able to get the board to achieve Deterministic latency. The vendor updated the layout to fix some noise issues (ie. DAC clock was being picked up by the ADC on the board) and this fixed the issue. we were never able to determine which of the many layout changes made fixed the issue. They have since sent me a board with newer ADCs installed and I can only achieve deterministic latency on one of the channels of this board. The failing channel exhibits the exact same behavior I was seeing with the original board.

Reply
  • I was never able to get the board to achieve Deterministic latency. The vendor updated the layout to fix some noise issues (ie. DAC clock was being picked up by the ADC on the board) and this fixed the issue. we were never able to determine which of the many layout changes made fixed the issue. They have since sent me a board with newer ADCs installed and I can only achieve deterministic latency on one of the channels of this board. The failing channel exhibits the exact same behavior I was seeing with the original board.

Children
No Data