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

  • I have also followed  the link delay setup with unknown delay procedure to configure the LMFCVar and LMFCDel registers and this has not helped. When I reset the link and read DYN_LINK LATENCY register (0x302). The values I get range from 0 to 7. I was expecting that I would only see 3 or 4 different values not all. Is this telling me something important about the interface and what might be wrong?

    These are the register settings I am using to program the AD9164

    0x000 0x18
    0x001 0x80
    0x0D2 0x52
    0x0D2 0xD2
    0x606 0x02
    0x607 0x00
    0x604 0x01

     Delay 2mS
     
    0x058 0x03
    0x090 0x1E
    0x080 0x00
    0x040 0x00
    0x09E 0x85
    0x091 0xE9
    0x0E8 0x20
    0x152 0x00

     Delay 20mS

    0x300 0x00
    0x4B8 0xFF
    0x4B9 0x01
    0x480 0x38
    0x481 0x38
    0x482 0x38
    0x483 0x38
    0x484 0x38
    0x485 0x38
    0x486 0x38
    0x487 0x38
    0x111 0x00
    0x230 0x28
    0x289 0x04
    0x084 0x00
    0x200 0x00
    0x475 0x09
    0x110 0x80
    0x453 0x87
    0x456 0x00
    0x458 0x2F
    0x459 0x23
    0x45D 0x4b
    0x475 0x01
    0x201 0x00
    0x2A7 0x01
    0x2AE 0x01
    0x29E 0x1F
    0x206 0x00
    0x206 0x01
    0x280 0x03
    0x268 0x22
    0x039 0x04
    0x03A 0x01
    0x300 0x01
    0x304 0x01
    0x306 0x09
    0x024 0x1F
    0x4BA 0xFF
    0x4BB 0x01

     Delay 100mS

    0x300 0x00
    0x475 0x09
    0x110 0x80
    0x456 0x00
    0x459 0x23
    0x477 0x00
    0x475 0x01
    0x300 0x01
    0x03F 0xCE

  • 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.

  • Hello,

    Sorry for the delay.  In the meantime, we are working on a procedure to use the SYSREF phase information to guide in the delaying of the LMFC at the source (FPGA).  This is a project we are working on as we have time.  IF you have further information from the FPGA side, let us know.

    Del

  • 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.

  • If after multiply POR cycles the Dynamic Link Register reports every possible latency between the LMFCrx and the LMFC aligned to SYSREF what is this telling me? What would cause the Dynamic Link Latency to take on every possible delay?