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.

DAC5682Z Spikes

Other Parts Discussed in Thread: DAC5682Z, DAC3484

Hello,

we are using two DAC DAC5682Z in a new our product. The instrument is a sort of waveform generator. The DAC are used without interpolation, only one channel on at 1 GSPS.

We are generating the 1 GHz clock with a CDCE6005 that provide also a 125 MHz clock to the FPGA device that generate the digital stream to the DAC. The FPGA generates the data using SERDES converters. Also the clock is generated using serdes providing the sequence 1010. We checked the frequency output from the FPGA (that is 500MHz) and we also analized the data bus and everithing is ok. The FPGA used is a Kintex 7.

We are following the startup sequence as is written  (exactly) on the datasheet.

Sometimes the DAC, after the initialization, start generating a signal with several spikes. To test the DAC behaviour we are generating a ramp with a counter in the FPGA. Each ns the DAC output increases by an LSB.  When the spikes they are allways at the same time distance; this means that the problem involves allways one bit (not allways the same). The problem is that this appens about the 4% of the times without any regularity.

There are some strange thinks:

1) If the DAC starts in the correct way (96%) it works correctly forever (we tested for several days)

2) If the DAC starts with the spikes the spike are present "forever". We have the possibility at runtime to shift date and clock. Any phase we select between clock and data the spike never disappear on the output (we can just make they stronger).

3) checking the DLL locked bit, DLL results allways locked

4) the datasheet suggests that for a 500MHz DLCK the correct value of the register 10 (DLL phase shift) is C0. My tests indicate that good results could be achieved  with 0x08.

5) with a clock of 500MHZ - 200Mhz (DCLK) the problem never happens.

Our idea is that the DLL sometime does not locked corrctly even if the lock bit is 1.

We tested almost everithing but now we need your help.

Thanks

Andrea Abba

  • Hi Andrea,

    I believe the person supporting the DAC5682z is out of office. In the mean time, here are some of my thoughts:
    1. If the on-chip PLL is used to provide the DAC internal sampling clock, please check the lock status in config0. This may cause glitches if the internal sampling clock have issue.
    2. When the spike occurs, check for errors such as FIFO errors. If there there interruptions to the CLKIN this would cause this type of sampling glitch. When the issue occurs, usually a re-sync (i.e. re-issuing a rising edge to SYNCp/n or perform a simple software sif_sync recover the output.
    A resync will not interrupt the DLL operation as long as the data and DCLK are still running. Perhaps a good ways is to perform software sync when problem occurs so you do not have to reconfigure the FPGA's LVDS path during debug.
    3. To check if the FPGA have any bit error while running, please perform pattern test by enable the pattern_err_mask in config3, send continous 0xAAAA and 0x5555 pattern to the DAC for the duration of the test, and monitor the pattern_err bit in config4.
    4. Does this issue only happen on some boards? or does it happen on all of your test platform so far? If it is an DLL issue on a particular part, then it should happen only on some boards. If it is an configuration error, then all the boards will have issue.

    -Kang
  • Hi Kang,

    thank you for your answer. We solved the problem this night. We are not sure about our solution.

    It seams that the problem appear only when you use software sync and not hardware sync. In principle  the datasheet says that you can use both software sync and hardware sync. We verified that only hardware sync works. Maybe there are some metastability issues on your internal FIFO on the transition of software sync. If you think the hardware sync is syncronous to the FIFO write clock because is generated by our FPGA. Software sync is syncronous to the SPI clock that is not generated by the FPGA. It that case maybe there is a silicon bug.

    We are using the DAC in the following configuration

    CLOCK IN 1 GHz LVPECL HIGH SWING NO PLL
    CLOCK DIGITAL 500 MHZ generated by a serdes in the FPGA
    DATA 1 GSPS
    DLL ON PLL BYPASS

    Please let me know

    Thanks

    Andrea

  • Hi Andrea,

    I believe you are on the right track because software sync is indeed asynchronous in nature. This is why you may need to adjust the FIFO offset (config1) and check for FIFO alarm (config4) after syncing to make sure the FIFO are in the optimal position. This has to do with the software sync to internal clocking handoff.

    The reason behind using software sync is to eliminate an extra IO for hardware sync. Some customers are willing to use additional software loop to correct for FIFO alarm instead of using hardware sync.

    You may find more information on the following app note:
    www.ti.com/.../slaa584.pdf
    Although the DAC3484 is a newer device, the concept of FIFO sync signal handoff is the same.

    Kang
  • Hi Kang,

    I can confirm that the issue appears only with software sync. No FIFO errors are generated even when the DAC doesn't work in the correct way. The problem appears only when SPI clock has no phase relation with the DATA clock. I think that you should verify this problem with your EVM and than put a warning on the datasheet. We lost about one 30 days of works due to this issue. Maybe this helps somebody else.

    Thanks

    Andrea