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.

DAC34H84

Other Parts Discussed in Thread: DAC34H84

We are observing interesting things right now.

Our DAC34H84 is set to have 250MHz data clock, 1000MHz DAC clock and 300MHz NCO clock.

We've seen multiplied elements(spurs) of ~ 7.75MHz regardless output signal Frequencies. Which means that we've seen Fout +/- (7.75MHz x N), N = 1, 2, 3, .....

Any ideas? Thank you.

  • new2day,

    We are looking into this.

    Regards,

    Jim

  • new2day,

    What is the input to the DAC? If a tone, what frequency? Can you send the DAC register settings? Are you filtering the output? Is this a custom board or a TI DAC EVM?

    Regards,

    Jim

  • We have 16 points complex data at 0dBm to the DAC. The data clock is 250MHz. It's a customer board. 

  • Hi Jim,

    Any updates on the synchronization? Thank you.
  • new2day,

    This document should help with your issue.

    Regards,

    Jim 

    DAC Synchronization.pdf

  • Hi Jim,

    It doesn't help. 

    Here are some funny observations:

    1. observed 4nS between two DAC devices when configured as below,

    1) set both DAC Data clock and DACCLK at 250MHz, no DUC (RAW data)

    2) FIFO are disabled

    3) registers 0x1E, 0x1F and 0x20 stay at their defaults

    3) same ISTR to both DAC chips

    2. observed also 4nS between two DAC devices when configured as below

    1) set both DAC Data clock and DACCLK at 250MHz, no DUC (RAW data)

    2) FIFO enabled

    3) registers 0x1E and 0x1F stay at their defaults while 0x20 was set to x"2201" that's single source SYNC mode

    4) no FIFO alarm from register 0x5 

    3. observed also 4nS between two DAC devices when configured as below

    1) set both DAC Data clock and DACCLK at 250MHz, no DUC (RAW data)

    2) FIFO enabled

    3) set registers 0x1E, 0x1F, 0x20 and 0x00 as the Table 8 in "slaa584", especially step 30 to 42 in the Table



    By doing the same above and set interpolate to 2 and DACDCLK from 250MHz to 500MHz (no mixer), the time delta changed to 8nS instead of 4nS. 

    I'm running out of ideas now!

    Our design and PCB layout are very carefully done for the high speed and synchronous operations, in which

    1. all LVDS buses (Data/ISTR/SYNC etc) well matched in length between two chips 

    2. OSTR and DACCLK are well matched between two chips and they from the same PLL

    3. OSTR and DACCLK P/N leg things have been taken in consideration agaist the datasheet

    4. DAC Data clocks are sourced from the same PLL as OSTR and DACCLK 

    5. so on and so forth. the same scheme have been implemented on all our products and we never have this alignment issue 

    Long story short, to get 4nS in dual-SYNC-source mode, I'll have to set to single-SYNC-source mode first. Otherwise = if doing what's shown slaa584 or the datasheet withotu doing through single-SYNC-source first, the  it'll be random xxnS offset between two DACs.

  • Hi,

    Any ideas or suggestions. It's very urgent about this multi-device SYNC problem. 

    Thank you very much.

  • new2day,

    You must use the FIFO and dual sync source mode for the most precise control. From what you mention above, when you are using the FIFO, you are using single source mode. Give this a try.

    Regards,

    Jim

  • Hi Jim,

    Yes, dual-source-SYNC is recommended by the datasheet so that our design is 100% following it. However, 

    However, the problem is, as mentioned several times before, it didn't give us precise phase alignment and it's worse by using dual-source-sync mode and do what's stated in the datasheet and slaa584. 

    The best can get so far is using single-source-sync. 

    Again, the problem is could not get precise phase alignment and it's worse by using dual-source-sync mode and do what's stated in the datasheet and slaa584. 

    Have any one ever make it work before by doing what's stated in the datasheet??? 

    What there somethings else differ from the datasheet??? Thanks.

    Regards,

     

  • Hi Jim and all,

    Any updates?

    Regards,

    Ying
  • Hi New2day,

    The DAC34H84 (the DAC348x family) has been used by many of our customers in applications requiring multi-device synchronization. So far, we have not observed any issues. Most of the initial issues are due to sequencing of the clocks, OSTR, and configurations. Let's take a look at couple of key points to see if we can narrow down the cause:

    Timing of the clock, OSTR, and ISTR

    1. Briefly looking at this history, I see that you have taken care of all the timing requirements for the clock setup. I just want to emphasize again that it is very important that the clock distribution for the DAC devices must have precise alignment of DACCLK and OSTR. Multiple copies of DACCLK and OSTR must be precisely aligned to ensure the FIFO read pointer are read at the same time instance.

    2. the data coming out of the FPGA must be send in the same order among multiple DAC devices. The order of the data is registered through the ISTR signal. The idea is that you must load the data in the same fashion, let the FIFO absorb the timing variation, and read back the FIFO at the same exact time instance.

    Configuration:

    1. Besides the FIFO read/write pointer setup in config 0x20, you must also enable the clock divider setup. Please ensure that the clock divider sync is enabled through config 0x00, bit 2. 

    2. syncsel_fifoin(3:0) must be set as ISTR, and syncsel_fifoout must be set as OSTR. Please set clkdiv_sync_sel as OSTR as well. The clock divider for the internal logic must be synchronized at the FIFO output side through OSTR to ensure all logic latency are the same among multiple devices. They are located in config32, 0x20 register

    3. syncsel_fifo_input must be set to 0x00 in 0x1F register. This ensures the routing of the LVDS ISTR external signal is routed correctly internally.

    4. Is NCO or any of the DSP logics such as QMC enabled? If so, could you disable them temporarily to see if the baseband signal is being aligned correctly. The NCO and QMC requires additional steps to ensure the logics are initalized to achieve the same latency.

    5. Is on-chip PLL enabled? If so, additional requirements on the PFD must be met. 

    If you can share your start-up sequence + programming, I can take a look as well.

    -Kang

  • Hi Kang,

    The data coming out of the FPGAs are in the same order onto all chips.  DACCLK and OSTR are aligned.

    please see below about Configuration: 1 to 5 

    1. Reg 0x00, bit2 = "1";

    2.  syncsel_fifoin(3:0) = "0010"; syncsel_fifoout(3:0) = "0100"; clkdiv_sync_sel = "0";

    3. syncsel_fifo_input = "00"

    4. not DSP, no QMC. Just real mode and RAW data

    5. on-chip PLL is not enabled.

    Regards,

    I've noticed that it's not always there was correlation between FIFO alarm vs. phase alignment.

    Regards,

  • DAC34H84 basic set-up sequence with dual-source SYNC for raw data (no DUC)
    after set-up the clocks and OSTR
    step register direction value
    1 toggling DAC reset
    2 Set TX_ENABLE to LOW
    3 0x2 WR 0x7082
    4 0x1B WR 0x0800
    5 0x00 WR 0x009C
    6 0x1E WR 0x9999 or 0x1111
    7 0x1F WR 0x9990 or 0x1110
    8 0x20 WR 0x2400
    9 0x05 WR 0x0000
    10 toggling ISTR (Low-to-HIGH)
    11 0x05 WR 0x0000
    12 read Reg 0x05 
    13 check the FIFO alarm and repeat 10-to-12 unitl all alarms clear 
    14 0x1F 0x4440
    15 0x00 0x0098
    16 0x20 0x0000
    see no difference with or without 14-to-16 here

    may need to play the FIFO offset sometimes between 10-to-13 or so

  • Hi Kang,

    any updates? thanks.

    Regards,

  • One question, would ISTR have to be periodic signal if OSTR is periodic signal? Thanks.

  • Hi New2day,

    new2day said:

    One question, would ISTR have to be periodic signal if OSTR is periodic signal? Thanks.

    No, not necessarily, as long as you can ensure that the initial ISTR signal would have the same deterministic latency (i.e. no change in delay) as the theoretical periodic ISTR. The problem with the initial ISTR is that the FPGA's state machine (depending on the firmware design) may change the characteristic of the overall FPGA timing when compared with the initial ISTR timing. This problem could potentially change the latency on the "normal" operation stage of the FPGA+DAC setup when compared with the initial latency setup. The advantage of continuous ISTR is that you can always be certain that the FIFO gets reset according the new timing information of each stage of FPGA timing. The disadvantage is perhaps you will see additional coupling of the ISTR modulated onto the DAC output in double side band modulation manner.

    To help isolate your problem at this point, I propose to do the following:

    Goal: to ensure everything after the FIFO output (i.e. all the DSP logics are in sync among multiple chips

    Summary: send DC type signal at the FIFO input so the FIFO input timing is not time variant. Enable coarse mixer and NCO to ensure the OSTR timing to initialize the DSP logics are good to ensure output phase matching.

    1. send a full-scale negative or positive signal (DC, static) through the LVDS bus by setting all 32-bit LVDS bus to be logic high or low (i.e. 0xFFFF or 0x0000).

    2. change 2's complement bit in config2 to 1b'0 to set to offset binary. At this point, DC values from the FPGA will be full-scale to the DAC. data to the FIFO input is not time variant and remains constant.

    3. Start the DAC as normal, provide DACCLK and OSTR to all DAC devices with same latency as normal.

    4. Enable coarse mixer. Walk the coarse mixer setting from Fs/2, Fs/4, and to Fs/8. Compare the output of the channel A, B, C, and D among multiple DAC devices. The output should be phase aligned. 

    a. config 2, bit 6 should be enabled to enable coarse mixer

    b. config13, bit 15:12, set CMIX setting per table 8

    c. note. If the FIFO output side and all the clock dividers are synchronized correctly by the DACCLK and OSTR, then the coarse mixer logic should be initialized as well without further tuning. If not, double check on the DACCLK to OSTR timing. Also double check on the clock divider initialization sequence.

    5. repeat with NCO enabled. Make sure NCO is synchronized by the OSTR in config31, bit 7:4. NCO frequency cycle may be impacted by the periodicity of the OSTR, please check the app note for the periodicity requirement. Simply set to multiples of OSTR frequency to simplify the problem.

    If both step 4 and step 5 are successful, then we need to narrow down the problem the FIFO input side. Once we narrowed it down, we can discuss further.

  • OK, we'll try it. Stay in tuned. Thank you.

    Like to mention again, we are able to get 4nS delta consistently between channels all the time (from each triggering) with single-source SYNC. 

  • Hi Kang,

    ** Have tried with Fs/4 and Fs/8 and all '0' to the DACs. The output were not aligned.
    ** Have check the DACCLK and OSTR, DACCLK are aligned on each DAC so as the OSTR
    ** have check the OSTR and DACCLK, they are 180 degree offset
    ** See below the sequence, was there anything missing there? Thank you.

    DAC34H84 basic set-up sequence with dual-source SYNC for Fs/8 mixing
    after set-up the clocks and OSTR
    step register direction value
    1 toggling DAC reset
    2 Set TX_ENABLE to LOW
    3 0x2 WR 0x70c0
    4 0x1B WR 0x0800
    5 0x00 WR 0x009C
    6 0x0D WR 0x8400
    7 0x1E WR 0x9999 or 0x1111
    8 0x1F WR 0x9990 or 0x1110
    9 0x20 WR 0x2400
    10 0x05 WR 0x0000
    11 0x05 WR 0x0000
    12 0x1F 0x4440
    13 0x00 0x0098
    14 0x20 0x0000

    see no difference with or without 12-to-14 here
  • Waiting for the feedback, thanks.

    Also like to mention once again, there is no guarantee correlation between FIFO alarms and  output alignment. For instance, phase were not aligned when there no alarms.