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

problem facing while testing dac3482 in tx mode

Bisal Pati
Prodigy 120 points
Other Parts Discussed in Thread: DAC3482

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. Here FIFO collision is happening.

Note:

  1. I am sending data from FPGA as 16bit/DDR@240MHz
  2. DAC is in dual sync mode and the read side of fifo is w.r.t 120MHz clk
  3. Frame is aligned to 1st data
  4. Interpolation Factor : 4X
  5. Able to perform pattern checker test but in this also fifo collision is happening even though IO_test_alarm is not getting generated.

Please revert if you need any other information.

  • 0
    Prodigy 120 points
    some more information:
    1. DACCLK is 960MHz
    2. Not able to clear the alarms (i.e fifo collision) in anytime. in the datasheet its written write to clear config5 but not sure to write 1s or 0s.

    1. what is the read clock frequency of the fifo??

    Any help on this will be highly appreciated.
  • 0 in reply to Bisal Pati
    TI__Guru* 78264 points
    Bisal,

    while the pattern checker test is enabled, the other alarms besides the IO_test_alarm should be ignored because the other test logics are not enabled.

    Please check the DAC3482 datasheet, page 32 to see if the FRAME and OSTR signal are correct given the interpolation setting. The FIFO read clock frequency is not a concern since it is internally generated and should be correct if all other settings are correct.

    Please clear alarms by writing all 0s.

    Also please refer to the app note below for dealing with FIFO collision situations:
    www.ti.com/.../slaa584.pdf

    -Kang
  • 0 in reply to Kang Hsia
    Prodigy 120 points
    Hi Kang,

    Thanks for your reply :-)

    some more informations and experiments on this :
    1. The dataclk is 240MHz, frame is 30MHz and DACCLK is 960MHz
    2. I tested the DAC by making ostrobe as 30MHz. And this time am getting fifo collision intermittently. sometimes am getting other statuses like 1 away, 2 away or fine (seems like an improvement)
    3. In pg-50 of the dac3482 datasheet, you have given some formulae to calculate FRAME and SYNC frequencies. So according to those (with 4X interpolation factor) ostr frequency should be 15MHz. could you please tell me if this is an issue??
    4. In data lines from FPGA to DAC am sending same data on both rise and fall edges but everytime only rise parity alarm is getting generated.

    Regards,
    Bisal
  • 0 in reply to Bisal Pati
    Prodigy 120 points
    sorry I just missed these infos:

    1. 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).
    2. once enabled, actual data and frame will be transfered continuously.
    2. but ostrobe signal is a continuous clk, by default.

    Will this be a problem??
  • 0 in reply to Bisal Pati
    TI__Guru* 78264 points

    Bisal,

    I believe you are using word wide (16bit LVDS bus) mode, 4x interpolation. Therefore, you must follow page 32, equation 2 and 4 for FRAME and OSTR frequency. They should be at maximum of 15MHz. This may explain the reason FIFO collision keeps occuring. The read/write process is simply too fast for the setting of 30MHz before. 

    You have to ensure that the FRAME and OSTR phase remains the same (i.e. no time delay shift or phase shift) as the FRAME transitions from non-continuous to continuous mode. The idea is that once the FIFO is synchronized and initialized at start-up by the initial FRAME pulse and OSTR pulses, the subsequent pulses should line up where the FIFO pointer should be as if they were continuously running. Otherwise if there are phase shift along the way, the FIFO pointers may get re-aligned and cause some warnings or errors.

    Basically, the FIFO by itself need an initial alignment by FRAME and OSTR to ensure the internal FIFO speed matches the whole system clock. Once it is initialized, the FIFO should run continuously unless there are interruption from DATACLK, DACCLK, FRAME, or OSTR. Re-issuing FRAME and OSTR, if they are phase shifted from expected time frame, will re-align the FIFO again, potentially causing collision. 

    -Kang

  • 0 in reply to Kang Hsia
    Prodigy 120 points
    Hi Kang,

    thanks a lot again for your reply :-)

    with these inputs I am able to test the DAC and this issue is closed.

    Regards,
    Bisal