On 09/23/2014 04:20 AM, Slichter, Daniel H. wrote: > The distributed RTIO core idea is more scalable, but as Sebastien > points out would represent substantial effort. It would also add > latency for feedback operations relative to the current system, > although if implemented in a simple way (essentially as a large, dumb > SerDes with an RTIO core, no soft processor) this latency might not > be too large.
Yes. I imagine we can have a small FPGA (XC6SLX9 or maybe even LX4 in TQFP144) containing just the RTIO core and the DDS driver core on a Wishbone bus, that is bridged to the Wishbone bus of the main SoC (on the KC705) over the serial link. We can add one pair connected to a RTIO channel on both ends for the software to determine and compensate for the latencies in the system. This makes a total of 3 pairs that can be carried over standard HDMI or DisplayPort cable and connectors. We cannot use the data pairs for synchronization, as the latency of the transceivers might not be the same in both directions. If we want to use long cables, it is even possible to compensate for the propagation delay in the synchronization pair (~15ns for a 3m cable): * the core device sends a synchronization pulse at timestamp 0 * the target device receives it with timestamp t1. t1 contains the propagation time plus the yet unknown skew from the core RTIO to the target RTIO: t1 = p + s * the core device instructs the target device to send back a pulse at timestamp t1 + dt (with a known dt, which must be chosen large enough for the process to have enough time, and small enough for the effect of the frequency instability of the clock to be negligible) * the core device receives it with timestamp t2 * t2 = t1 + dt - s + p = 2p + dt, so: p = (t2 - dt)/2 and s = t1 - p. Maybe a good option is to run the first experiments on the Papilio Pro (its main disadvantages are a low number of RTIO channels and a slow communication link with the PC) and implement directly the distributed RTIO scheme on the KC705-based systems. Perhaps still have a simple breakout board as an intermediate/temporary solution on the KC705. On 09/23/2014 05:53 AM, Robert Jordens wrote: > 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. Are we going to fix that? Sébastien _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
