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.

DAC3482: DAC3482: sometimes output is delayed (continue)

Part Number: DAC3482

Hi,

 

Sorry for delay response. this is continue question to below

https://e2e.ti.com/support/data-converters/f/73/t/878522

 

My customer has had an experiment on their system. then they observed an interesting result.

Normally, single sync pulse at first is allowed to make synchronous when single sync source mode. But my customer see delay clock out sometime. If second sync pulse inputs, no delay clock out observed, looks solving this issue.

 

Do you know why second sync pulse make solving this issue?

 

In addition, I would like to confirm delay time.

The 20ns of delay time is clock of FIFO block, right?

If so, is the correct way to input data 100MHz x 16bit with I / Q multiplexing?

 

Best regards,

Katsu

  • Katsu

    Katsu Matsunaga said:

    My customer has had an experiment on their system. then they observed an interesting result.

    Normally, single sync pulse at first is allowed to make synchronous when single sync source mode. But my customer see delay clock out sometime. If second sync pulse inputs, no delay clock out observed, looks solving this issue.

     

    Do you know why second sync pulse make solving this issue?

    This may not necessary be the DAC3482 issue. This is mainly due to the FPGA happen to be initialized finally right before the second sync pulse. During the initialization of the FPGA and DAC, there may be instability of the clocks throughout initialization. The first SYNC pulse may occur during initialization where the clocks are still be stabilized and the digital pattern are still being initialized. When the FPGA finally initialized fully, the second sync pulse will set the DAC3482 in correct operating mode. This had been a common trend from many of our customers, and therefore I have highlighted in the app note to make sure all the clocks and data are settled before issuing the SYNC pulse.

    Katsu Matsunaga said:

    In addition, I would like to confirm delay time.

    The 20ns of delay time is clock of FIFO block, right?

    If so, is the correct way to input data 100MHz x 16bit with I / Q multiplexing?

     

    See the diagram that I have highlighted in the E2E. Correctly, the FIFO clock is running at 50MHz, or 20ns period. The FIFO slip is mostly contributed by the FIFO clock level. 

    DATACLK is at 100MHz, DDR.

    -Kang

  • Hi Kang-san,

    Thank you for your response.

    I would like to confirm FIFO operation with DATACLK 100MHz.

    FIFO operates with DATACLK/2 as 50MHz. for IQ data handling, I data is handled at rising edge of FIFO's clock, Q data is at falling edge. In this case, FIFO seems to be running at 100MHz. Is this correct?

    Could you tell the IQ data handling in FIFO? Is it expected that about 20ns delay is observed also IQ data?

    Best regards,

    Katsu 

  • Katsu,

    The way the data is handled inside the FIFO requires details of our IP. We cannot disclose it, and can only disclose the FIFO is running at 50MHz. Any slippage in FIFO results in +/-20ns of latency delay. This is all we can disclose at this point.

    -Kang