• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 664 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DAC60501: DAC settling time clarification

rmalcovich
Prodigy 100 points
Part Number: DAC60501

We need a (relatively) cheap DAC to produce a ramp voltage with a update rate of ~1uS per step.Since fully specified 1uS settling voltage DACs are quite expensive, we investigate the possibility to use a little slower device, like ~5uS as DACx0501. The board is cost sensitive, ie. > 500pcs to be produced.

Settling time is specified from 1/4 to 3/4 full scale.

We need to settle from one LSB to another (up or down) and according this fig. of datasheet (glitch impulse), we should be fine, about 1uS

SPI interface is specified to 50 MHz. However, there is a parameter in datasheet that isn't appearing in timing diagram, nor specified anywhere

tDACWAIT Sequential DAC update wait time min. 1uS

According to our calculations (assuming 50 Mhz), timing diagram should be as follows

NotOh.png (1077×885)

I have 1.65uS and I need 1uS :))

The question is about that tDACWAIT parameter, why to wait for?

  1. Wait because of DAC analog circuitry needs to settle and in this case, I can ignore a little. While DAC settle, I can write a new value over SPI.

  2. Wait because DAC analog still reads from digital section, faster will put other data and confuse output.

  3. No idea, combination of above?

To be more clear, this is how I plan to use it, not necessarily violate parameters, depends how I understand that tDACWAIT

Thanks a lot for clarifications!

  • 0
    TI__Guru 53633 points

    Hi,

    Thanks for the great diagrams! 

    The answer is a combination of 1 and 2.  Right after the DAC latch the data (rising edge of CS), a subcircuit called the "track and hold" is enabled.  This basically blocks the output from seeing the internal ladder from changes.  This is to reduce the code-to-code glitch.  After a few hundred nanoseconds (nominally), the hold releases and the output is connected.  At that time you will see a small glitch.  You can see that in the glitch diagram that the output does not change in the first ~400ns.  This is the track and hold time.  

    tDACWAIT is saying that you should not trigger another latch event until the TnH is complete.  Across temperature, supply voltages, and process the track and hold time can vary, so tDACWAIT is a bit conservative.  Your last figure is a good example. Basically, try to space the rising CS edges 1µs apart and you will be good to update at 1MSPS.

    That being said, even at 1LSB steps your DAC might not be fully settled, so analog settling might still be an issue in your design.  Figure 36 shows the glitch at midscale, which is usually the worst-case glitch, you can see the output takes more than 1µs to settle.

    I will also lobby to get the tDACWAIT added to the timing diagram.

    Thanks,

    Paul