This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC5681 problem getting a DLL Lock

i have an FMC110 card that we have been trying to get a DLL lock on for quite sometime. The Clocking is as follows: the AD5917 sends us a 200MHz clock on a pin configured for the card, and the DAC gets clocked at 400MHz, bit clock of the OSerdes is at 200MHz DDR rate, the DCLK output (Oserdes pattern sending 1010) from simulation looks to be 200MHz clock, i.e, at 200MHz the pattern 1010 generates a 200MHz D-Clock(bit clock) for the DAC. The issue is, this D-CLOCk is about 103 ps late from the data transitions on the other SERDES outputs  I don't have ODELAYS (i know this is my own design issue and need to resolve it). My question is, would this actually prevent the DLL from locking? Is this the culprit for why there is no lock on the DLL for my design? As of right now, I can't get a DLL Lock at all. I have tried numerous times to follow the recommended procedure on page 40. My config10 value is C8 with the above frequencies i mentioned.

Also does it matter if Data is toggling on the LVDs buses before a sync event?

Another question I want to ask is, is the training sequence provided as "0xAAAA55555...", really for confirmation of LVDS bus receiving the correct bits? I was under the impression that as long as DLL locks, there's no need for an elaborate training (state machine) to configure the DAC as long as D-Clock is working properly and the sync event had had happened on the clock edge that corresponds to a bit transfer on any one of the samples? (fig 38 shows a 0->1 transition on sample 2 but that's just for saying that the sync happened on sample 2)



  • Hi Sam,

    It sounds like you're within the skew parameters (tskewA and tskewB) specified for a DCLK of 200 MHz in the datasheet. With a 200 MHz DCLK you are right on the edge of two different config10 settings. Have you tried using 0xCF in config10?

    Verify that you are not bypassing the DLL accidently by using DLL_bypass in config5.

    Make sure you are taking the DLL out of reset by setting DLL_reset in config8 to 0.

    If you're reading back status0 for the DLL lock bit, make sure your SPI readback is working by checking the device_ID parameter.

    The training sequence can be used as a system level test on power up or at production to verify that the interface works correctly. It is not required for the DLL to work properly.

    Matt Guibord