Thank you David and Dan. The information you gave is very useful. I see that I need to plan for my two ADC's to be out of sync by as much as four nanoseconds when I run an ADC at 2 GHz. The good feature is that the difference in phase should stay constant during a run if I use the same oscillator to clock both ADC boards. That may be all I need.
> Hi, Ron, > > On May 6, 2013, at 2:28 PM, [email protected] wrote: > >> Having one ADC filling the FIFO with >> its own clock would cause one signal to have a >> delay relative to the other. Are you suggesting >> the FIFO in the FPGA corrects this problem by >> cancelling the delay? > > I don't know how/whether the ADC yellow blocks account for this (very > shallow) ADC1 FIFO delay by delaying the ADC0 data accordingly. I have > never thought about what portion of the measured relative delay was due to > clock demux ambiguity vs unaccounted for clock-domain-crossing FIFO > latency. > > When comparing the output of two ADCs, the relative delays need to be > measured after every programming of an associated FPGA. Between > programmings, the relative delay due to the clock demux ambiguity and > clock-domain-crossing FIFO latency (if any) is very stable. Maybe you > could get away with measuring it every power cycle on the ROACH/ROACH2 > rather than every time you program the FPGA. > > I've only dealt with this on multi-iBob systems where the FPGA has a > built-in PPC that boots every time the FPGA is reprogrammed. As I > mentioned in earlier emails, the iBob startup code would reset (both!) the > ADCs until they came up in sync with each other. This was actually > detrimental because resetting ADC0 made the FPGA clock go away and come > back which caused clocking havoc. It also meant that the ADC clock delay > ambiguity relative to other iBobs was not constant across reprogramming > the FPGA even though it would have been had the ADCs not been reset by the > startup code. I think it was a well intentioned "feature" that had some > unintended side effects. > > We typically measure the relative delays by injecting correlated noise or > observing a broadband calibrator (e.g. a quasar), correlating the inputs, > and then fitting a phase slope across the cross correlation frequency > spectrum. This also measures other sources of relative delay such as > mismatched cable lengths. > > Dave > > >
