I think we're making this too complex at this stage. I gather we're in agreement that the short-term goal is to get ARTIQ up and running as quickly as possible in some labs using existing TTL and DDS hardware. I propose postponing the task of improving upon the current parallel LVDS bus. A straight-forward solution is to draw up a pair of daughter cards for the FMC connectors: one for the TTL/PMT bus and a second for the DDS bus.
Ingredients: * reuse sn65lvdm1677 transceivers which have built-in 110 Ohm termination * our existing SCSI cables are HPDB68 (68-pin) * put 50-pin IDC ribbon cable connector on daughter cards * use a IDC to SCSI adapter (under proper detensioning) to interface with the SCSI cable (which tends to torque a lot) e.g. http://www.patchcords.com/scsi-internal-to-external-adaptor-idc-50-pin-male-to-hpdb-68-pin-female/ -Joe Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.gov > -----Original Message----- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > Jordens > Sent: Monday, September 22, 2014 3:54 PM > To: artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] DDS/TTL breakout boards > > 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 _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
