• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 893 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DAC38J84 -- DACA/B and DACC/D seem to be offset by 1 sample

Graeme Smecher
Intellectual 415 points
Other Parts Discussed in Thread: DAC38J84, DAC38J84EVM

I have a design with multiple DAC38J84s with outputs that must be precisely synchronized. Each DAC38J84 is running at 2 GSPS internally. However, even on a *single* DAC38J84, it looks like there's a single-cycle (500ps) delay between the AB and CD paths.

Here's a scope trace, with a delightful cameo by yours truly:

DACA and DACC are captured on a fast scope in yellow and cyan. The chartreuse trace shows SYSREF heading into the DAC; an edge is obscured by the legend on the right-hand side of the screen.

Most of the DAC setup is deliberately bypassed here to emphasize the unexpected delay. We've configured a sinusoid via the NCO, and routed (via config34) all 4 DACs to use path A. The discontinuity indicated by the scope's vertical cursors is due to a SYSREF edge clearing the NCO counters (and is, again, deliberate.)

In this mode, we were expecting DACA and DACC to track each other perfectly. Instead, we're seeing a 500ps delay between DACA and DACC. (We've validated that A/B are consistent, and C/D are consistent, but the two groups have a single-cycle delay.) This delay seems to be consistent across the other DACs we've looked at.

Any suggestions? I don't see anything in the datasheet stating this is expected behaviour. Our SYSREF setup/hold times look fine, and we are resetting the PLL counters using it.

thanks,

Graeme

  • 0
    TI__Guru 68704 points

    Graeme,

    I would expect the 4 paths out of the DAC38J84 to be inherently synchronized. I will have to look into this on my side and get back to you.

    In the mean time, could you please check the following:

    1. config36, bit6:4 (clock divider initialization). Please advise how it is configured. The clock divider block provides internal divided down clock to various digital blocks. Without properly initialized by the SYSREF signal, it is possible that the internal blocks have different clock phases from the un-synchronized dividers. This could be one cause of the 1-clock cycle delay.

    2. There is a coarse delay setting in config15. Please advise if both channel A/B path and channel C/D path have the same setting.

    -Kang

  • 0 in reply to Kang Hsia
    Intellectual 415 points
    Hi Kang,

    Thanks (again!) for the quick turnaround.

    I just verified that setting config36=0x10 does not remove the 0.5ns offset between A/B and C/D. This uses the same configuration as above, so we have visual confirmation that SYSREF is hitting the part (by watching for discontinuities generated by NCO resets.)

    Also, the coarse delay (config15) is equal for both paths. By adding a single-cycle delay to the C/D path, we can compensate for the unequal delay -- but that doesn't explain why it's present in the first place.

    Don't hesitate to ask if there are any other register settings you'd like to confirm here. I can also probably send you a piece of Python code that illustrates how we're configuring our DACs.

    thanks,
    Graeme
  • 0 in reply to Graeme Smecher
    TI__Guru 68704 points
    Hi Graeme,

    Could you confirm if the time delay holds when NCO frequency change? Just checking if this is a constant time delay or a phase delay.

    -Kang
  • 0 in reply to Kang Hsia
    Intellectual 415 points
    Hi Kang,

    Good thought. The delay is a constant 500ps irrespective of NCO frequency.

    In case you were wondering if our NCOs were not aligned -- we were able to route path A to both DACs A and C using config34[7:0]. In this mode, the same NCO is used in any case and the mysterious delay remains. Whatever's causing the delay must either be in the clock tree, or after this multiplexer.

    best,
    Graeme
  • 0 in reply to Graeme Smecher
    Intellectual 415 points

    Hi Kang,

    Have you had a chance to investigate? We're heading into the Christmas season (I'd imagine you are too), and I'd like to get this issue wrapped up before we lose momentum.

    thanks,

    Graeme

  • 0 in reply to Graeme Smecher
    TI__Guru 68704 points
    Hi Graeme,

    sorry for the late response. I have been doing some experiments on and off, but I was not able to duplicate the 1 output sample off issue.

    I have tested our DAC38J84EVM with our HSDC PRO software. My configuration was 500MSPS input, 4 lanes, 4x int at 2GSPS output.

    the following are my tests:
    1. inject a CW tone from our HSDCPO software at 30MHz, observe channel A, B, C, and D. Fine mixers and CMIX are off. 4x int only.
    2. set the NCO to 100MHz. observe output delay. For fine mixer initalization, I have tried both the sif_sync and also syncing from SYSREF like you did.
    3. set fs/8 CMIX. observe output delay
    4. repeat 2 and 3 with constant input. observe output delay.
    5. repeat the experiment with direct resistor termination to ground to avoid any LC time constant effect. Each leg is terminated 25 ohm to ground.
    5a. repeat the experiment with lower clock speed - i.e. 500MSPS. This way if there is indeed a 1 output clock sample offset, the offset will be more significant to observe on the scope.

    All of the experiment results indicate that the A and C, and B and D channels are synchronized. The design team also confirmed this. Scopes were DC coupled and calibrated for timing purposes.
    We have many customers using this device for phase array application where device synchronization is critical. So far, we have not heard any issue reported regarding the inherent device output delay.

    I would recommend let's try the following:
    1. inject a known tone to the DAC on your system instead of using constant input.
    2. use coarse mixer such as fs/8 such that initialization of the counter may not be a factor here.
    3. reduce the DAC clock rate to see if the 1 sample offset is tracking with clock rate. If at very low clock rate the sample still have 1 clock rate off, then we need to look into the clock trees. If not, I suspect there may be something on the output network introducing some sort of LC time constant on the delay.

    Steps 2 can be done with constant input as well just to eliminate variables from the JESD link.

    I will think of some more tests to do as well and try a few more things here.

    -Kang
  • 0 in reply to Kang Hsia
    Intellectual 415 points
    Hi Kang,

    We've reproduced our test setup and tracked the problem to a faulty SMA cable. We'll be in touch if we run into any other problems... in the meantime, thanks again for your all your time and help. I really appreciate having prompt and knowledgeable support for these parts. Happy holidays!

    best,
    Graeme
  • 0 in reply to Graeme Smecher
    TI__Guru 68704 points
    Hi Graeme,

    thanks for the update. Was the faulty SMA cable connected to the DAC output port? Just trying to understand the root cause and also to add to the knowledge bank to the E2E site, that's all.

    -Kang
  • 0 in reply to Kang Hsia
    Intellectual 415 points

    Hi Kang,

    Yes, exactly. This cable was not matched to its mate, so any test of single DAC came up with an unmatched delay. With tested, matched cables, the two channels on any single DAC align beautifully.

    best,

    Graeme