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

From CMB-S4 wiki
Revision as of 12:20, 19 October 2019 by Nwhitehorn (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Link back to agenda


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?


  • 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]


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


  • 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


  • 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