This is mostly to tell our story with the AD9129 but also a question we still have.
Sometimes we got PLL lock failures and DLL loss failures, to counter this we do retries where we write the setup again.
We tried listening on the Eval board what was actually written to the DAC through the SPI and found it was completely different from the proposed setup in the datasheet.
So we changed the setup accordingly but still got various failures. We searched on the board and found that someone suggested first setting the DLL duty cycle correction on before enabling the DLL, this gave a much better result. We also changed the setup of register 0x34, with start write of 0x55 then 0x5D or 0x6D (we support both options).
But we still had failures, this time seemingly FIFO failures. We could not see any logical status in register 0x05, but the output was corrupted, our CW looked like a mix of a triangular and sine wave with some ghostly noise. Investigation of this showed that FIFO thermometer values would show 0x1F 0x3F 0x3F 0x3F when the corrupted output occured, all other status would give us fine CW.
In our startup procedure we run SED and trim delays both in the FPGA and the 0x0A register in the DAC. So we do a full trim of everything. Our clock is the ADF4351. DCI is produced by a Xilinx Kintex 7 FPGA ODDR directly from the DCO.
We sometimes use 2.5GHz clock but we also support programmable clock. And we power down the DAC when it is not used. Even the FPGA is sometimes powered down.
This has been one of the hardest ICs to bring up I have ever come across. We now believe it works every time but we still need to do more testing.
We still don't know why we get corrupted output when we read 0x3F from register 0x15, but if we just check for this and do a reset of the FIFO (writing register 0x11 with 0x81) we can get good output. Maybe ADI can answer this?
In case anyone wants to know how we got to this we are willing to share our information within limits. Just write an email to firstname.lastname@example.org.