• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 46 subscribers
  • Views 1098 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DAC3482: DAC3482 post power on initialization collision

Shishir Chakravarthy
Prodigy 20 points
Part Number: DAC3482

Hi,

Our design involves a DAC3482, with digital samples being supplied at 480MHz DDR by an FPGA (DATA_CLK =  480MHz) and DAC_CLK at 960MHz. Hence an interpolation factor of 2 is chosen. Power-on sequence was followed as per the datasheet. Timing constraints have been taken care at FPGA end. Following are the register settings applied at the DAC :

config1  :  0x050E
config16 :  0x3000
config5  :  0x0000     (Cleared alarms)
config27 :  0x0800         
config32 :  0x2201   (Single Sync source mode with Frame being used at the sync signal)
config0  :  0x019C    (Interpolation set to 2x)
config9  :  0x8000
config2  :  0xF002    (Word-wide mode, 2's compliment format)
config7  :  0x4063    (Only alarm from PLL is masked, others are enabled/unmasked)
config36 :  0x0000  (data_dly and clk_dly are made 0, since this is taken care of at FPGA end, by centre-aligning the data with respect to data_clk)

config5 : 0x0000 ( To clear alarms after power-on sequence)

After following this sequence, a register read of config5 shows no collision alarm (config5 : either of 0x0060, 0x0860 or 0x1860).

But after supplying the samples from FPGA, a collision occurs (config5: 0x3960), which after clearing once goes back to 0x0060 (no collision). There is no report of collision then onwards.

Any help in debugging this issue would be much appreciated.

Note: Same experiment carried out with DATA_CLK = 240MHz and DAC_CLK = 960MHz with 8x interpolation caused no issues such as the above mentioned one.

Regards,

Shishir

  • 0
    TI__Genius 12780 points
    Hi Shishir,

    I am taking a look at this, and will get back with you soon. Is using OSTR (Dual Sync Source Mode) an option for your design?

    Regards,

    Dan
  • 0 in reply to dBrock
    Prodigy 20 points

    Hi Dan,

    As per your suggestion, we experimented on the OSTR option in dual sync source mode. OSTR clk was derived from the same source as the 960MHz DAC_CLK, from a programmable clock synthesizer on board.. As per the datasheet, we are required to generate

    fOSTR = fDAC/(n x interpolation x 16) where n = 1, 2, … can repeat multiples of 16 FIFO samples for World-Wide Mode. So fOSTR = 960/(1 x 2 x 16) = 30MHz as per our requirement.

    Also config32 was changed appropriately to 0x2400.

    Result of this experiment was collision always without being able to recover from it (even after clearing alarms in config5).

    Also, it is not possible in our existing architecture to generate fOSTR less than 30MHz (which is the lower end limit).

    Please advice further as to what can be done with either dual sync source mode or single sync source mode.

    Regards,

    Shishir

  • 0 in reply to Shishir Chakravarthy
    TI__Genius 12780 points

    Hi Shishir,

    Thanks for giving that a try. You seem like you know quite a bit already, but we have an application report that applies directly to FIFO configuration and synchronization for the DAC348x family that I think may help in the debug efforts. There is also advice here in regard to the initialization process.

    Have you tried to use the sif_sync while in single sync source mode? This acts as another way to update the FIFO pointers. You can synchronize on both sif_sync and FRAME (for fifoin and fifoout) simultaneously in register config32. Also, you could try adjusting the FIFO in/out pointers.

    I have contacted the designers, and will let you know as soon as I have more information.

    Regards,

    Dan

  • 0 in reply to dBrock
    TI__Genius 12780 points
    Shishir,

    I was able to speak with one of the designers. Another thing to keep in mind is that the alarms are "sticky", so they do not self clear. It is entirely possible that you are getting a collision when you are sending the data from the FPGA since the FIFO pointers have not been yet been aligned/synchronized. This kind of alarm is to be expected, and, as long as you do not get subsequent collisions, your FIFO buffer should be working properly.

    Consider it this way. Without an input to the FIFO buffer (digital data and DATACLK from FPGA), the input FIFO pointer is not moving, but the output FIFO pointer is still moving along since its synchronization is derived from the DACCLK. This will cause a collision alarm since the output pointer is landing on the same spot in the input pointer is resting at every time it goes from 0-15 (or 0 - 7 for byte case). Once you start sending your digital data and DATACLK from the FPGA to the DAC, the input FIFO pointer will synchronize and shift in unison with the output FIFO pointer. After clearing the alarms at this point, there should be no further collision alarms, and it sounds like this may be what you are seeing.

    Regards,

    Dan