• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 5444 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.

DAC3174: DAC3174

Vikas Kumar40
Intellectual 630 points
Part Number: DAC3174
Other Parts Discussed in Thread: LMK03200, , DAC3171, ADS54RF63

I am using DAC 3174 at 150 MSPS . Clocks are provided by LMK03200. The frequency generated is 30 MHz. I am not using sync and allign signal. They are left as it. In the programming registers, I am disabling sync as well. But the problem is some times, the DAC output is clean  and sometimes its kind of oscillation. I have monitored the data also. Data is coming proper

  • 0
    TI__Mastermind 29220 points

    Hi,

    if you are not using the SYNC and ALIGN inputs, then the FIFO must still have an initialization event for both sides of the FIFO.  After an initial hardware reset, the FIFO may be initialized with a software SYNC, called a sif_sync.   Set the register bit for sync_only which means that the align input is not needed and the sync signal is used to reset both sides of the FIFO.   Then set the sif_sync_ena to one with sif_sync still set zero.   Then on another SPI write set the sif_sync to one.  This makes a low-to-high internal transition for the SYNC signal, which will be used to initialize both sides of the FIFO.  This seems to me to be the most likely issue from what you have described.

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points
    Hi Richard

    As per your suggestions
    I am writing these registers.
    Address 00-06ed
    01-601e
    02-603e
    03-0c00.

    One mistake has happened that sync and allign , I got it connected to LMK03200 which can give only clock signals.
    Now if am not using sync and allign, any hardware jumpers I need to put.
  • 0 in reply to Vikas Kumar40
    TI__Mastermind 29220 points

    Hi,

    Did you really mean address x02 data x603E after address x01 data x601e?   That should be address x01 getting x601e and then address x01 getting x603e.    No writes to address x02.

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points

    Hi Richard

    Sorry for the error. Its

    Address 00-06ed
    01-601e
    01-603e
    03-0c00.


    Now the question is registers are okay only. Then the issue. Do I have to make any hardware changes.?

  • 0 in reply to Vikas Kumar40
    TI__Mastermind 29220 points

    Hi,

    I don't know what your hardware looks like so I do not know if you would need to make any changes.  But since you mentioned that sometimes the device operates properly and at other times not, it would seem likely that there is something in error with the initialization of the device.  are you applying a reset pulse to the device before configuring it?  What is your complete set of programming to the SPI registers?

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points

    Dear Sir

                   I am giving the reset pulse before configuration. For SPI writing, I am writing only these registers.

  • 0 in reply to Vikas Kumar40
    TI__Mastermind 29220 points

    Hi,

    There are many things that could possibly cause intermittent behavior if not checked, such as checking the DACCLK for sufficient amplitude *and* common mode if not AC coupled as on the EVM.  Or possibly the timing requirements listed in section 6.8 of the datasheet might not be met.  How did you arrive at the value of 0x0C00 for address 0x3?   The DATA must meet setup and hold time around the DATACLK, and while I don't know the timing of your data out of your FPGA the SPI register it is possible that 0x0C00 is just right - but how did you arrive at that value?  That value puts 000 for the delay field for both halves of the data bus, datadlya and datadlyb.  but clkdlya is 011 and clkdlyb is 000.   I expect you would want this the other way round.  The field clkdlyb is actually the field that sets the delay for DATACLK.   The field clkdlya sets the delay for the SYNC input.  (The DAC3171 datasheet has a better diagram in Figure 68 for this than the DAC3174 datasheet does.)   The reason for this confusion in which field is the right one for the data clock is that in dual bus mode with dual clocks, the clock for bus A is what used to be the SYNC input.   And the clock for bus B is what used to be just called DATACLK,   thus - clkdlya is the delay for SYNC and clkdlyb is the delay for DATACLK.  You might want 0x0030 for Config3.

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points
    Richard
    The datasheet says that Dataclk and Data should follow DDR concept but the page no 35 says its on rising edge for 14 bit mode. At the power on the spectrum is very clean, but after sometime, it looks like oscilaation. I checked the LMK03200 output, its locked properly. I dont think , this could be timing issue.
  • 0 in reply to Vikas Kumar40
    Intellectual 630 points
    Richard
    For Device 3171, software sync is valid for 14 bit data as well or only 7 bit DDR data. ??
    I think, some setting I am missing. If the issue is resolved, I can used the same device for higher IF as well.
  • 0 in reply to Vikas Kumar40
    TI__Mastermind 29220 points

    hi,

    page 35 of what datasheet?  Must be the DAC3171 datasheet.   You started off the posting saying you are using a DAC3174. 

    For the DAC3174 (2 channel operation) the 14 bit data bus is shared between channel A and channel B.   in 14bit mode the sample for channel A is latched on one edge of the DATACLK and the sample for channel B is latched on the other edge of DATACLK DDR fashion.    There is the option to split the 14bit data bus into two 7 bit busses where one set of 7 bits are for channel A in DDR fashion, and the other 7bit but is for channel B.   In this mode half the sample is latched on the rising edge and half the sample on the falling edge.      Either way, the input latches will latch all data bits on rsing edge and all the data bits on falling edge and after the input latches a multiplexor will steer the proper bits towards channel A or B depending on the 14bit mode or 7 bit mode.   *IF* you are not using the sif_sync then you would need to use the SYNC input to reset the FIFO pointers in the FIFO regardless of mode of operation.

    If you are using the DAC3171 (1 channel DAC) the data that would have been latched for channel B is not used for anything.  So yes, for this device in 14bit mode the data of interest would only be latched on rising edge.  (The device is still internally latching data on falling edge but it doesn't go anywhere.)   But if you use the DAC3171 in 7bit bus mode then the data is latched on rising and falling edges - half a sample on rising and half on falling - on those 7 inputs for that channel.    You would still need SYNC to reset the FIFO pointers unless you are using sif_sync.  

    The input latches simply latch all data bits on both edges all the time.   Depending on 7bit or 14bit mode of operation a multiplexor sorts out which bits are for channel A and which are for channel B.  Then the samples for both channels go to the FIFO, which will need a SYNC event of some kind whether the SYNC input pin or the sif_sync.     If the one channel DAC is used then the bits that would have gone to channel B no longer matter, so then you could not worry about what data is on the falling edge of DATACLK in 14b mode or not bother to drive the unused 7 inputs in 7bit mode.   But the FIFO operation is no different between the 1 channel or 2 channel devices, whether in 7b or 14b mode.

    Regards,

    Richard P.

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points

    Hi Richard

                         The problem got solved. Actually it was some kind of sequencing issue. AD9959 is driving LK03200 and LK03200 is driving the DAC. I was giving the control instruction to all of them at the single shot. I provided sequencing and the issue got resolved. Now only problem I am facing is little bit variation in phase noise at 1 KHz. It keeps on fluctuating for 5 dBc

  • 0 in reply to Vikas Kumar40
    TI__Mastermind 29220 points

    Hi,

    Thank you for letting us know.  I am glad it is resolved

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points
    Richard
    Thanks for the support during this DAC as well as ADS54RF63. Because of your support, ADC is working at 550 MSPS on the customized board with almost datasheet SNR.

    I wanted to ask you, I want to generate chirp signal at 120 MHz for 5 MHz bandwidth, so the DAC clock will go around 480 MHz, do you suggest to go with the same DAC or shall I upgrade for the next project. As I have observed spectral purity of DAC3171 is very good
  • 0 in reply to Vikas Kumar40
    TI__Mastermind 29220 points

    Hi,

    I am glad the system is working well for you.  For the signal you described, the DAC3171 would be a fine choice.  if it works well for you then I would stay with it. If you need higher sampling rate later or higher bit resolution then we have other DACs available at that time.   The DAC3171 family was created to be as simple a DAC as we could define for applications that do not need a lot of digital features that more complicated DACs have such as interpolation or NCOs and mixers, etc.   But if the DAC3171 meets your needs then I think it would be the simplest device to stay with.

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Intellectual 630 points
    Hi Richard

    Thanks for the suggestion
    Regards
    Vikas.