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: DAC81416 LDAC and Busy (Alarm) Questions

Part Number: DAC81416
Other Parts Discussed in Thread: AM2434, , DAC8568

Hi, I am using an AM2434 to program a DAC81416 where LDAC is being independently triggered by an external clock. As soon as LDAC is triggered, I am loading the next set of DAC values ready for the subsequent LDAC.

Question 1:

The LDAC input appears to be level sensitive rather than edge triggered (e.g. not like a DAC8568). What I mean is that if LDAC is held low and I write to a DAC output register, the output changes immediately rather than on the next LDAC falling edge. Is my understanding correct? If so, please clarify in the manual.

This behaviour is not the end of the world but it does mean extra work to manage the LDAC duty cycle.

Question 2:

I have read threads here discussing the timing of LDAC to CS (as in it needing to be ~2.4us). I have discovered that I can map the busy bit to the Alarm pin and use the rising edge (i.e. DAC going not-busy) to gate the writing of the next DAC values. Is this an acceptable method?

Question 3:

Do I need to add a delay between writing to the DAC output registers in synchronous mode? I have a natural delay of ~126ns at the moment. It seems to work reliably but should I use the busy bit? My concern is that I will exceed the update time budget. 

Incidentally, the sequencing of LDAC is not clear in the manual - a timing diagram would be most helpful.

Thanks,

Steve

P.S. FYI, I have attached the current timing diagram showing the sequence (ignore the glitches on the Alarm signal - it's a bench rats nest testing the limits of physics). Is there a better way of sequencing this?

  • Oh, I forgot to mention that I think there's an error in 8.3.3.3 Software Reset - do you mean reserved code 0b1010 (0xA) instead of 0x1010?

    Thanks, Steve

  • Hi Steve,

    I will look and get back to you by end of today.

  • Hi Steve,

    Please see my response

    Question 1:

    The LDAC input appears to be level sensitive rather than edge triggered (e.g. not like a DAC8568). What I mean is that if LDAC is held low and I write to a DAC output register, the output changes immediately rather than on the next LDAC falling edge. Is my understanding correct? If so, please clarify in the manual.

    This behaviour is not the end of the world but it does mean extra work to manage the LDAC duty cycle.

    [AM]:  to operate LDAC in synchronous mode the following register writes to be done.

             1.   0x06, 0001 // DAC0 SYNC  enable for LDAC trigger

             2.   0x0E, 0010 // Enable SYNC mode 

    Question 2:

    I have read threads here discussing the timing of LDAC to CS (as in it needing to be ~2.4us). I have discovered that I can map the busy bit to the Alarm pin and use the rising edge (i.e. DAC going not-busy) to gate the writing of the next DAC values. Is this an acceptable method?

    [AM] : ALMOUT pin dedicated status output for thermal shutdown. . i coudn't able understand what you want to try.

    Question 3:

    Do I need to add a delay between writing to the DAC output registers in synchronous mode? I have a natural delay of ~126ns at the moment. It seems to work reliably but should I use the busy bit? My concern is that I will exceed the update time budget. 

     [AM]: You have to consider output setting time which limit DAC update rate, you have to wait at least 12 usec between writes  

      

  • Thank you for your response Anbu.

    Regarding Question 2: I am setting bit 10 in SPICONFIG as per your manual:

    This seems to do what it says - i.e. the Alarm line goes low on the falling edge of LDAC.

    Is my understanding correct?

    Thanks, Steve

  • Question 1:

    The LDAC input appears to be level sensitive rather than edge triggered (e.g. not like a DAC8568). What I mean is that if LDAC is held low and I write to a DAC output register, the output changes immediately rather than on the next LDAC falling edge. Is my understanding correct? If so, please clarify in the manual.

    This behaviour is not the end of the world but it does mean extra work to manage the LDAC duty cycle.

    [AM]:  to operate LDAC in synchronous mode the following register writes to be done.

             1.   0x06, 0001 // DAC0 SYNC  enable for LDAC trigger

             2.   0x0E, 0010 // Enable SYNC mode 

    [SRS]: I am setting the bits in register 6 but I am NOT using the software LDAC - I am using an external LDAC signal. Please confirm if LDAC is level or edge triggered?

    Question 2:

    I have read threads here discussing the timing of LDAC to CS (as in it needing to be ~2.4us). I have discovered that I can map the busy bit to the Alarm pin and use the rising edge (i.e. DAC going not-busy) to gate the writing of the next DAC values. Is this an acceptable method?

    [AM] : ALMOUT pin dedicated status output for thermal shutdown. . i coudn't able understand what you want to try.

    [SRS]: I am setting bit 10 in the SPICONFIG as per your manual in order to have a physical Busy signal. Please confirm that it's acceptable to wait for this signal before updating DAC registers (note my timing diagram in original post).

    Question 3:

    Do I need to add a delay between writing to the DAC output registers in synchronous mode? I have a natural delay of ~126ns at the moment. It seems to work reliably but should I use the busy bit? My concern is that I will exceed the update time budget. 

     [AM]: You have to consider output setting time which limit DAC update rate, you have to wait at least 12 usec between writes  

      

    [SRS]: My question is regarding the timing between register writes - I have noted the 25 ns for CS high time so I'm using this value as a minimum.

    Thanks, Steve

  • Hi Steve,

    Question 1:

    The LDAC input appears to be level sensitive rather than edge triggered (e.g. not like a DAC8568). What I mean is that if LDAC is held low and I write to a DAC output register, the output changes immediately rather than on the next LDAC falling edge. Is my understanding correct? If so, please clarify in the manual.

    This behaviour is not the end of the world but it does mean extra work to manage the LDAC duty cycle.

    [AM]:  to operate LDAC in synchronous mode the following register writes to be done.

             1.   0x06, 0001 // DAC0 SYNC  enable for LDAC trigger

             2.   0x0E, 0010 // Enable SYNC mode 

    [SRS]: I am setting the bits in register 6 but I am NOT using the software LDAC - I am using an external LDAC signal. Please confirm if LDAC is level or edge triggered?

    [AM]: Hardware LDAC is edge triggered one and you have to enable this with writing (0x0E,0x0010). 

    Question 2:

    I have read threads here discussing the timing of LDAC to CS (as in it needing to be ~2.4us). I have discovered that I can map the busy bit to the Alarm pin and use the rising edge (i.e. DAC going not-busy) to gate the writing of the next DAC values. Is this an acceptable method?

    [AM] : ALMOUT pin dedicated status output for thermal shutdown. . i coudn't able understand what you want to try.

    [SRS]: I am setting bit 10 in the SPICONFIG as per your manual in order to have a physical Busy signal. Please confirm that it's acceptable to wait for this signal before updating DAC registers (note my timing diagram in original post).

    [AM]: Yes, generating LDAC based on ALAM bit (enable as BUSY bit)  acceptable approach and ensure settling time must meet to between the LDACn signal.  

    Question 3:

    Do I need to add a delay between writing to the DAC output registers in synchronous mode? I have a natural delay of ~126ns at the moment. It seems to work reliably but should I use the busy bit? My concern is that I will exceed the update time budget. 

     [AM]: You have to consider output setting time which limit DAC update rate, you have to wait at least 12 usec between writes  

      

    [SRS]: My question is regarding the timing between register writes - I have noted the 25 ns for CS high time so I'm using this value as a minimum.

    [AM]: Yes, 25ns timing is enough and not additional delay needed.