search

sinara-hw / FMC_Shuttler

16-channel 125MS/s 16bit DAC in FMC form factor.
15 stars 4 forks source link

DAC alignment #5

Closed tprzywoz closed 3 years ago

tprzywoz commented 5 years ago

Do we need clock distribution to DACs with adjustable delay between channels?

dhslichter commented 5 years ago

@tprzywoz @gkasprow the clock distribution for each DAC should be appropriately length-matched to the data traces for that DAC, but I don't think we care about whether these propagation delays are the same from DAC to DAC to less than ~1-2 ns (this should be very easy to achieve). It is not important that the DAC outputs all update exactly synchronously.

gkasprow commented 5 years ago

@dhslichter can you imagine application somewhere in the quantum lab where it could be important ?:)

jordens commented 5 years ago

For very wideband applications the different group delays do make a difference and it would be nice to compensate then in hardware. Narrowband phase shifts are relatively easy to compensate in software.

dhslichter commented 5 years ago

If it is easy to do, then go for it. My main purpose is to avoid over-specifying the board in a way that makes it harder to design or more prone to failure/breakage. @jordens I would think that any delays could be compensated for reasonably in software if desired. I'm not clear on what you mean by "group delays" here? Assuming this is all on the digital side that we are talking about, it's just a matter of whether the DACs are exactly synchronous in their output clocks (such that the phase is matched at the front panel analog output connectors, for example) or not. While this is a nice goal in principle, I can't imagine that for fast ion trap electrode control (the goal of Shuttler) that sub-ns delay variation (static, mind you) would be an issue.

jordens commented 5 years ago

Compensating for fractional, sub-sample, group delays in wide band applications is harder than compensating for a phase shift in a narrow band DDS. I would always prefer matching delays as good as reasonably possible on the board.

dhslichter commented 5 years ago

I am fine with matching delays on the board as best as reasonably possible, no reason not to. I just don't want to be doing crazy things for those last few picoseconds...

gkasprow commented 3 years ago

not relevant here. we will have a matched clock and data lines.