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.

DAC81416: The timing requirement of /LDAC and next data update cycle /CS

Part Number: DAC81416

Hi,

Regarding the DAC81416, is there any timing requirement between /LDAC and next data update cycle /CS ? The reason why ask is some channels of DAC81416 fail to output waveform as expected when we shorten the time between /LDAC and /CS.

In our design, we use LDACs siganls of different DACs to synchronize output voltage on different channels, different DACs. We met the requirement tLOGDLY(cs rising edge to LDAC falling edge) described in datasheet, detail of our experiments as following:

1. At first, the LDAC rising edge to CS falling edge (a new round of data transmission) are: DAC0 150ns, DAC1 790ns, DAC2 1430ns. Then most channels of DAC0 won't work, only one or two could output correct waveform. DAC1 channel 2~15 could output correct waveform, ch 0 & 1 won't work (can only output a fixed voltage, guess the firstpoint of the waveform) . DAC 2 all good.

2.Then we delayed the transmission of DAC0 & 1 to 1430ns (LDAC rising edge to its own CS falling edge). All channels of all DACs are good.

3. Then we try to put DAC 0 & 1 earlier, but still meet the 1us wait time as described in chapter 9.3.1.2.1 of datasheet.

3.1 DAC0 1030ns (LDAC rising edge to its own CS falling edge), DAC1 1190ns. Then only ch1(2nd channel) of DAC0 won't work (guess only output first point of the waveform), other 15 channels of DAC0 all good. DAC 1 & 2 all good.

3.2 DAC0 later to 1140ns, DAC 1 1270. The same as 3.1, only ch1 of DAC0 won't work, rest all good.

3.3 DAC0 more later, 1190ns (the same as DAC1's time in 3.1), DAC 1 1300ns. The same, only ch1 of DAC0 won't work, rest all good.

BR/Wang Peng

  • Hi,

    DAC to DAC update wait time is 2.5uS. In your case, for /LDAC fall edge to /CS fall edge, we can calculate the required time as follows.

    Assume SCLK frequency is 50MHz, you need min 24 SCLK cycles for SDI for a valid DATA transmission.

    So time delay should be min 2.5uS - 24*20nS = 2.02uS (min). This is because once you trigger LDAC low, previous DAC_DATA will be pushed to DAC_register and updates it. If you tranmit next DAC_DATA before the previous DATA updates, it can corrupt the DAC_DATA.

    Adjust the timing and let me know if this works.

    Regards,

    AK

  • Hi AK,

      Let me introduce some info. Our update period is P = 10us, the period of /LDAC. And we are using streaming mode to update the 16 channels, so the transmission time would be 5300ns. So my question is can t in the pic below less than 2.5us?? As I discribed, we tried 1030us, 1140ns, 1190ns all failed. But 1430ns succeeded. Any requirement on t here??

      We have 8 DACs on the board, and I want to pipeline the transmission to reduce the overlap for SSI.

      And the example you gave is just one channel updtaed, and the transmission time ls less than 2.5us. How about the transmission time larger than 2.5us??

      In the situation depicted below, the period P = 5300 ns + 20ns (tLOGDLY) + t. Could t be 0 ??

      Many THX.

  • Hi,

    In both cases t should be the value I mentioned earlier. It doesn't matter whether delay between \LDAC to LDAC is 2.5uS or 10uS.

    Regards,

    AK

  • Hi AK,

      How about the asynchronous mode? The 2.5us still valid??

      In my test, when t >= 1210 ns, all channels work fine, when < 1210ns, some channels would fail.

  • Hi,

    In asynchronous mode, /LDAC is not required. So this time will be applicable for /CS going low to /CS going low for DAC update. Exact time required will depend on the internal clock which is pushing the data from DAC register to DAC buffer.

    Internal clock is approximately 25Mhz (40nS), min time required will be 2.5uS - (24*40nS) = 1.54uS

    Regards,

    AK

  • Hi AK,

      So the tDACWAIT is applicable to asynchronous and synchronous mode. But just seems chapter 8.3.1.2 and 8.3.1.2.1 tell something different. It seems once data were transferred from buffer registers to the active DAC registers, we can write data to the buffer registers or just wait for 1us. And even this doesn't match the test results >= 1210ns and < 1210ns. How should I understand the two chapters?

  • Hi,

    As I said earlier, in asynchronous mode, we need min 1.54uS wait time.

    Will update the datasheet to reflect the same.

    Regards,

    AK

  • Happy Thanksgiving! I will update the code accordingly.

    Last question, the sequential update wait time is 2.4us or 2.5us?

  • Hi,

    Same to you.

    Please update the code with sequential wait time of 2.4uS (min) and I have calculated above using another 100ns buffer

    Regards,

    AK