On 09/22/2014 02:20 PM, Slichter, Daniel H. wrote: >> The receive parallel clock is reconstructed from the received data >> and the latency is constant once locked. > > Yes, but if this timing relationship is different each time the > system is rebooted (I have seen on datasheets that for some of the > gigabit systems e.g TI TLK2711A or TLK2521, it can vary from chip to > chip and relock to relock, up to ~half a parallel UI) then you will > have different skew across deserializer chips from power-up to > power-up.
This is not a new problem. In The Old System there is a variable alignment of SYNCLK to the other signals from reset to reset. To get accurate timing with the current hardware you will have to add a return channel for SYNCLK anyway. > The other issue is that any SerDes-type solution means we lose the > advantages of fine timing adjustment provided by the RTIO core, which > would let us perform deskewing of TTL pulses, for example, via some > calibrations saved in the parameter list. A compromise might be that > we could have a few direct channels to the RTIO core (in/out) over a > reduced-conductor parallel cable for signals (like FUD, DDS SNYC_CLK, > PMT counts) where we might care about timing to a high degree, and > then send the rest (DDS programming, most TTL outputs) over a high > speed serial link where we don't care about the timing resolution as > much. Yes. Robert. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
