UCSD-2019: Cross-Cut: Readout/DAQ/Control Testing

Link back to agenda

Charge

What interfaces do we want/have between readout and DAQ? What does readout need from DAQ? What does DAQ need from readout? Do any of these items affect readout downselect?

Open Questions:

• What do we need to have a data transport interface that meets our data loss requirements?
• What quality of timing (1/f and jitter) do we need for readout noise requirements to be met? Can DAQ deliver this (at all or with the chosen transport technology)?
• What integration complexity do we expect for readout control?
• How do we coordinate development of readout control?
• What is needed from DAQ for laboratory testing?

Agenda

• 8:30-8:45 SPIDER TDM DAQ (Sasha) [1]
• 8:45-9:00 SPT3G fMux DAQ (Sasha) [2]
• 9:00 - 9:15 BICEP mumux (Ed Y.) [3]
• 9:15 - 9:30 SO mumux (Jack L.) [4]

Notes

Need to provide support for both current and future versions of technology on a short timescale.

TDM

• No clock constraint
• MCEs require rare and hard-to-obtain PCI cards with custom driver -- long-term issue
• Low data bandwidth (downsampling in crate)
• Scalar readout
• Future version of TDM should use ethernet
• 50 MHz reference clock on MCEs, incompatible with distribution choices
• Many hardware parts for working system
• Software for MCEs exists, but legacy
• Direct FPGA register control from DAQ computer
• No channel-mapping ambiguity

FDM

• 10^-10 clock constraint at 1 Hz
• IceBoards connect by Ethernet + 10 MHz + IRIG, easy in lab
• Indirect, high-level control by HTTP through embedded ARM
• Timestamp-based synchronization
• Vector readout + metadata
• No DAQ-side dedicated hardware
• Channel-mapping ambiguity
• Mature modern software stack (3G + PB2)

mumux with SMuRF

• Unclear timing requirement
• Ethernet downlink, but needs to be terminated in FPGA board
• Extremely high bandwidth, needs extra fiber
• Scalar readout + metadata
• Channel-mapping ambiguity
• Custom timing signals
• Maturing, modern software stack (SO)
• Data format evolving