Dear Thomas,
On Monday, October 03, 2016 11:18 PM, Thomas Harty wrote:
I guess you mean propagation delay temp. co. + long-term stability,
right?
Yes. Your document mentions a <0.1deg error at 3GHz which corresponds to
100fs, but it doesn't say over what period of time that error is
accumulated.
I haven't tested this for the HMC7044 yet, but I'm happy to
add it to the list of ICs to test.
I have a couple questions/comments for you, but first let me check I
understand your plan at a high level:
- We have a rack with both AMC (digital) and RTM (RF) backplanes -
The MCH (Metlino) receives a 100MHz clock from one of various
sources
There are only two sources possible for the Metlino:
1) 100MHz received directly when in root mode, and converted to 200MHz
RTIO clock
2) 200MHz recovered from DRTIO fiber when in satellite mode (with more
than one crate). Using the recovered clock here avoids a CDC in gateware
and associated non-deterministic-latency issues.
- The MCH communicates with the AMCs via the AMC backplane
using Gigabit transceivers clocked at n*100MHz (say, 1GHz-10GHz)
Correct, or fiber to another crate or to a Kasli, which hopefully will
get built.
-
Each AMC recovers its RTIO clock by integer division of the recovered
gigabit transceiver clock (e.g. to 125MHz)
Yes, and the satellite Metlinos (if any) also do.
- The RTIO clock shall be
the same for all devices, but is globally tunable over some specified
range
Yes. If we want tunability, we may have to use PLL synthesizer chips
instead of XOs; as I mentioned in my email the Xilinx transceivers are
not very flexible when it comes to synthesizing frequencies.
- The DAC data rates/TTL phy clocks are power-of-two multiples
of the RTIO clock
Multiple yes, power-of-two helps but is not strictly necessary, Robert
already wrote on this topic.
- The DAC is clocked from one of various sources,
such as an integer-N PLL locked to the 100MHz RTM clock
- The ADC is
clocked from an integer division of the DAC clock
Both would be synthesized from 100MHz by one HMC7044, so yes.
For the synchronisation:
- SYS_REF is generated by integer division of the DAC clock, and is
routed from the divider (HMC704x) to the DAC using length-matched
traces, such that it's phase relationship to the DAC clock is
well-known
- SYS_REF is operated at an integer division of the RTIO
clock
- SYS_REF is also routed to the FPGA using a length-matched
trace
- As a result, SYS_REF has the same phase at the FPGA as at the
DAC
- The FPGA measures the phase of SYS_REF w.r.t. the RTIO clock by
scanning its IDELAY
- The FPGA then programs the phase of the SYS_REF
output of the HMC704x to align the DAC/ADC clocks + SYS_REF signals
with the RTIO clock. This alignment needs to be good to better than 1
DAC clock cycle (i.e. <<400ps)
Not necessarily length-matched, but with a known length.
Robert also pointed out that with the HMC7044 we can scan its fine
delays (which are potentially better calibrated than the Ultrascale's
IDELAY) instead of using the IDELAY. My email was assuming the AD9516-1
there, which has a limited number of fine delay blocks.
Also, - Why do you require a 125MHz XO on the Sayma? Is this just
used for startup until the RTIO clock can be recovered from the
gigabit link?
Simple convenience and the 125MHz frequency is not critical. This
oscillator is not meant to be used as transceiver clock.
The transceivers do however always need an external clock even when
receiving, to provide a reference to the CDR. In the scheme I proposed
it is the same frequency as the RTIO clock, typically 200MHz.
Regards,
Sébastien
_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
