Difference between revisions of "UCSD-2019: Cross-Cut: Readout/DAQ/Control Testing"

From CMB-S4 wiki
Jump to navigationJump to search
 
Line 20: Line 20:
 
* 9:15 - 9:30 SO mumux (Jack L.) [https://docs.google.com/presentation/d/1u1QovfC_Snc3ge3omNs3ExMVCWOqgviGKpmOzHCoAjk/edit?usp=sharing]
 
* 9:15 - 9:30 SO mumux (Jack L.) [https://docs.google.com/presentation/d/1u1QovfC_Snc3ge3omNs3ExMVCWOqgviGKpmOzHCoAjk/edit?usp=sharing]
  
== Remote attendance ==
+
== 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<sup>-10</sup> 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 ===
  
== Notes ==
+
* 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

Latest revision as of 12:20, 19 October 2019

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