Hi, Ron, On May 6, 2013, at 2:28 PM, r...@physics.ucsb.edu 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
