DAC5670-SP - what happens

Alexandr,

We have been updating the datasheet to improve the information on use of the DLL, and document how to use it without the DLL.  This new datasheet should have posted to the web yesterday.

The device was not specifically designed to by synchronized for IQ.   I have heard of another customer using it for this, but I do not know if successful, nor the methodology used to insure synchronization.   I do not expect we will be creating application note on synchronizing 2 DAC5670's as this time.

Regards,

Wade

Dear Wade

Thank you very much !!!

new datasheet is available now, going to study it

Dear Wade

let me ask you one more question regarding internal timing of this DAC

Assume, my goal is to get stable known delay from DACCLK input to DLYCLK output

As per new data sheet, I understand that holding RESET signal high, we can "bypass" DLL , or, in other words,we prevent variable delay block in clock path from adjusting its delay, thereby placing it in known state... am I right?

Also, there are two other dividers by two in clock path....

So the question is :

can you provide information about timing of this three blocks in RESET='1' state? Is their delays known and stable? Is there any numerical info about this delays?

Thank you in advance.

Alexandr,

You are correct.  Holding RESTART will essentially keep the DLL delay elements in a fixed position.

The delay from DACCLK to DLYCLK with RESTART asserted is not known on a particular device.   Additionally, it is difficult to discern what edge of DACCLK should be relevant, as data is 1/4 of DACCLK, and is DDR.

If a mechanism was employed to determine which edge of DACCLK to use for the setup/hold, then this would allow better control.  Unfortunately, I do not see a way to do this without moving the relationship and evaluating the correct edge from performance criteria.

Regards,

Wade