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.

fifo collision is happening in dac3482

Other Parts Discussed in Thread: DAC3484

Hi,

I am using DAC3482 in one of our boards where am trying to test the DAC in tx mode.

Here are the observations and experiments that I carried out:

  1. I clocked the DAC
  2. Then I performed power-up sequence for the DAC.
  3. I sent the data from FPGA continually.
  4. Then I enabled the DAC in tx mode.
  5. But the output from dac is not as expected.
  6. And FIFO collision is happening.

some more informations :

  1. I am sending data from FPGA as 16bit/DDR@125MHz
  2. DAC is in single sync mode Interpolation Factor : 8X and dacclk is 1000MHz
  3. by default, frame signal is not continuous. when the start data transfer signal is enabled then both actual data and frame will be transfered to DAC from FPGA else no valid data or frame (means zeros).
  4. sleep pin is connected to ground.
  5. generating one frame pulse on every 16 clocks of 125MHz clock
  6. Able to perform pattern checker test.

Please revert if you need any other information.

  • Bisal,

    I thought we already closed this issue. Please advise how this issue is different than the one listed here:
    e2e.ti.com/.../1728063

    The debugging process will be the same. The FIFO collision is entirely due to the external clocking factors. Please look into your FPGA design to see the changes that you made between 4x int and 8x interpolation.

    -Kang
  • Hi Kang,

    Thanks again for the reply :-)

    Actually am facing this in a different board and am using the same procedures where we had closed the issues.

    The only difference here is interpolation factor is 8X and clock frequencies (dataclk = 125MHz and dacclk = 1000MHz)

    But there are some observations like below :

    1. after giving the clock to dac, if i will read config5 register am getting 0xBB7B (fifo collision)
    2. then, after performing power-up sequence if i will read config5 register am getting 0x3960 (fifo collision) and in this step am sending all zeros in data pins and zero in frame pin from fpga. At this time i tried to clear the config5 reg by writing 0x0 to it but still am reading 0x3960 only
    3. then i started giving the frame signal on every 16 samples of data(all zeros) but config5 is still 0x3960 (fifo collision). I tried to clear the config5 reg by writing 0x0 to it but still am reading 0x3960 only
    4. am using frame as my syncing source for both input and output side of fifo

    so, what could be possible reasons for this? is it happening because of clocks or someting else?

    Regards,
    Bisal
  • Hi Kang,

    some more observations :
    1. with 500MHz dacclk clock am not getting any problem and here am getting expected analog output but with 1000MHz dacclk am getting fifo collision intermittently.

    is it happening because of only clock or can be someting else (for example :- due to frame signal)?

    waiting for a reply...

    Regards,
    Bisal
  • one more observation :
    with 1000MHz dacclk if i will give 4X interpolation (even though dataclk is 125MHz : seems like wrong :-) ) am getting 1 away or 2 away and able to see the expected analog output.

    And here am generating frame on every 16 clocks of dataclk.

    Any help on this will be highly appreciated.... :-)
  • Bisal,

    I have a feeling that you are either in byte wide input mode (vs. 16 bit bus mode config2 bit15) or your interpolation setting is wrong (config0, bit11:8)

    Please provide your exact clocking condition, register setting (in txt format, preferably in DAC3484 GUI format). I can check.

    Please also adjust your FIFO offset setting in config9 to see if FIFO collision went away. The exact mechanism for FIFO offset adjustment is highlight in the app note.

    Finally, please apply only one time FRAME pulse to the DAC. In single sync source mode, continuous FRAME sync signal is *not* recommended.

    -Kang