Difference between revisions of "UCSD-2019: Cross-Cut: Readout/DAQ/Control Testing"
From CMB-S4 wiki
Jump to navigationJump to searchNwhitehorn (talk | contribs) (→Charge) |
Nwhitehorn (talk | contribs) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
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?''' | 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 == | == Agenda == | ||
| − | * 8:30-8:45 SPIDER TDM DAQ (Sasha) | + | * 8:30-8:45 SPIDER TDM DAQ (Sasha) [https://docs.google.com/presentation/d/1oz1cpAYTk8aFEhgeF2yJPYxXQCLurEuN_TbaOgI6A_4/edit?usp=sharing] |
| − | * 8:45-9:00 SPT3G fMux DAQ (Sasha) | + | * 8:45-9:00 SPT3G fMux DAQ (Sasha) [https://docs.google.com/presentation/d/1oz1cpAYTk8aFEhgeF2yJPYxXQCLurEuN_TbaOgI6A_4/edit?usp=sharing] |
| − | * 9:00 - 9:15 BICEP mumux (Ed Y.) | + | * 9:00 - 9:15 BICEP mumux (Ed Y.) [https://drive.google.com/open?id=1CBfOWxz_6FaTsB3N0ZTLzSSHcip1NeaTvNSG6Melha8] |
| − | * 9:15 - 9:30 SO mumux (Jack L.) | + | * 9:15 - 9:30 SO mumux (Jack L.) [https://docs.google.com/presentation/d/1u1QovfC_Snc3ge3omNs3ExMVCWOqgviGKpmOzHCoAjk/edit?usp=sharing] |
| + | |||
| + | == 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 === | ||
| + | |||
| + | * 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
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
