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
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
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 0x180x001 0x800x0D2 0x520x0D2 0xD20x606 0x020x607 0x000x604 0x01
Delay 2mS 0x058 0x030x090 0x1E0x080 0x000x040 0x000x09E 0x850x091 0xE90x0E8 0x200x152 0x00
0x300 0x000x4B8 0xFF0x4B9 0x010x480 0x380x481 0x380x482 0x380x483 0x380x484 0x380x485 0x380x486 0x380x487 0x380x111 0x000x230 0x280x289 0x040x084 0x000x200 0x000x475 0x090x110 0x800x453 0x870x456 0x000x458 0x2F0x459 0x230x45D 0x4b0x475 0x010x201 0x000x2A7 0x010x2AE 0x010x29E 0x1F0x206 0x000x206 0x010x280 0x030x268 0x220x039 0x040x03A 0x010x300 0x010x304 0x010x306 0x090x024 0x1F0x4BA 0xFF0x4BB 0x01
0x300 0x000x475 0x090x110 0x800x456 0x000x459 0x230x477 0x000x475 0x010x300 0x010x03F 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.
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.
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.