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.

DAC81408: Timing for external LDACn inactive to CSn active.

Part Number: DAC81408

I have a design that uses the first 4 channels as arbitrary waveform generators running at a 400Khz update rate (at 50Mhz SPI) and then synchronously updating them. The four remaining DACs are used as utility DACs that can be updated at any time. My RTL design uses the streaming mode for the first 4 channels then tacks the channel update for one of the 4 utility dacks after the streaming of the first 4 DACs. However, after streaming DACS 1-4, then issuing an LDACn strobe, I run into issues if the next DAC is DAC5. the other 3 work fine. Is there a timing relation sip between the LDACn and selecting the next sequential DAC after the streaming selection?  

Again, my sequence is:

1) CS low

2) 72 bits transferred - DAC1_ADDR (8bits), DAC1_DATA(16bits), DAC3_DATA(16bits), DAC3_DATA(16bits), DAC4_DATA(16bits)

3) CS high

4) 20nS delay

5) LDACn Strobe for 20nS

6) 15nS delay

7) CSn low

image.png

  • Hi Louis,

    My colleague Uttam will respond to you when he is back in the office on Monday.

    Thanks,

    Paul

  • Excellent, I am running into all kinds of timing-related issues with the DAC81408 due to undocumented timing requirements. I know have the design mostly working accept that DAC1 only updates one out of 20-30 times writing to it but the remaining three in the stream mode work fine. There is some relationship not in the datasheet. Again, In my application, I need to update 4 DACs at a 400khz update rate and then one of the following of DAC 5-8 so I have 5 DAC updates per every 2.5uS. I think my issues are around the Toggle register B to Toggle register A timings but the datasheet mentions nothing about their relationship. In my design, the laser ARB waveforms cannot be interrupted.

    Lou Morrison

  • Hi Lou,

    Thank you for reaching out. I couldn't open your attachment. Could you please upload it again?

    Regards,

    Uttam Sahu

    Applications Engineer, Precision DAC

  • Hello Uttam,

    The attachment was a picture but I created a pdf and included it below.4087.DAC.pdf embedded in the email. 

  • Uttam,

    Is there any status on this? What is the timing relationship between LDAC and synchronous updates? After LDAC, when can CS go low again?

    Lou

  • Uttam,

    What is the timing relationship between LDAC going high and CS going low for streaming mode? My customer is late on their product delivery and I need to understand why the DAC updates sometimes but not other times? The resulting wave is supposed to be a smoothed sharkfin like waveform. This waveform is 400khz update rate to four DACs (DAC0-3) in streaming mode with LDAC to sync them.

     

  • Hi Louis,

    Apologies for the delayed response. The CS to LDAC timing is a minimum 20ns for 3.3V VIO. Looks like the DAC channels are settling in your test scenario. You can try slowing down the update rate and find out where exactly the waveform distorts. We can also analyze the timing of the SPI waveforms. It will be helpful if you can capture all the signals and upload here. You may need a bigger scope though.

    Regards,

    Uttam

  • Hey Uttam,

    I understand the CS inactive to LDAC active timing is 20nS, but I see the output of the DACs not transitioning correctly based on the LDAC active to the register access of the corresponding DAC on the next sample streaming sequence. If I decrease the DAC update rate to 5.0uS the outputs look perfect across all the channels. With an update rate of 2.5uS there are samples that do not update every access. The part behaves like I need 2.5uS timing from LDAC active to the next access to that DACs register. In other words, at 2.5uS update rate, DAC0 will output sever corruption and dropped data points, DAC1 has slightly less, DAC2 has less corruption than DAC1 and usually, DAC3 is little to no error in its waveforms. It is as if the DAC registers cannot be accessed at all for 2.4uS from LDAC low. The non-streaming mode works, but the DAC signals are not all aligned as I need them. Again, if I lower the update rate such that timing is 2.5uS from LDAC active to accessing DAC0's register in streaming mode, the signals all look great. Chill spray on the DAC part also improves the behavior.

    My RTL looks like this:

    DAC1_REG_ADDR = 8'h14;

    burst_data_in <= {DAC1_REG_ADDR,data_in1[15:0],data_in2[15:0],data_in3[15:0],data_in4[15:0]}; //72 bit streaming access

    Here is what channel 0 looks like. Notice how it just stops updating for a while then it updates every 4 samples.

  • Hey Uttam,

    I am getting closer to finding the undocumented constrain. I looks like the time from Active LDAC in synchronous mode and the rising edge of CS in async mode to the access of the DAC register being updated needs to be 2.4uS. So I am trying to figure out why it works sometimes but not others. Can I get a more detailed diagram or a description of what the state machine in the chip is actually doing when CS goes high or LDAC goes low?

    Lou

  • Hey Uttam,

    It looks like the DAC Buffer to DAC Active register transfer is getting stomped on in my situation. Is there a way to use the toggle mode and the DAC Buffer (Toggle Register B) directly to the DAC and skip the transfer to the DAC Active register (Toggle Register A). For example, if I want to continually stream DACs 0-3 via DAC Buffer (Toggle Register B) only. If I enable toggle mode for TOGGLE0 on DACs 0-3 and continually stream data to DACs 0-3, will the output DAC be updated for every sample I send? 

  • Hi Lou, 

    I believe I have recreated this issue on my bench, though I believe the critical timing that is at fault is really the relationship from the LDAC falling edge and the CS rising edge of the asynchronous update. 

    This is the basic pattern I was using:

    I then swept the timing between the synchronous update edge (falling LDAC edge) and the asynchronous update edge (rising CS edge). 

    I eventually found a timing window where both channel 1 (synchronous update) and channel 5 (asynchronous update) did not respond correctly.

    My suspicion is that there is a critical timing constraint that we are not meeting (obviously not in the datasheet).  I am working with my design team to verify this.

    I think one way we could get a work-around in your system is to set all 8 channels to synchronous mode (allowing them all to update on the LDAC edge).  Is that allowed in your application?

    Thanks,

    Paul

  • Hi Lou,

    As we have continued this discussion over email, I would like to close the thread.  I will summarize our discussion for future readers:

    Basically, the way tDACWAIT must be interpreted is as the delay between the latch edge and the CS falling edge of the next DAC command.

    This means that the maximum sample rate you will be able to achieve is:

    Where tWRITE is the you take to write the 4 inputs.

     

    If you are using a 50MHz clock, writing to 4 channels in streaming mode, we can estimate tWRITE = 72×20ns =  1.44µs (we still need to take CS into account).

    This means your SRMAX = 1 (1.44µs + 2.4µs) ≈ 260kSPS.