Interface Documents David Christian 11/20/17 Interface between CE - PowerPoint PPT Presentation

Interface Documents David Christian 11/20/17

Interface between CE and DAQ • Interface documents will define the boundaries of responsibility between the various consortia. • Project management (Steve Kettell) is pushing to get these drafted. • Steve has written a draft of the interface between Single Phase Electronics (us) and DAQ (attached). • I’m uncomfortable with aspects of Steve’s draft, but am unsure of how to modify it. • David Cussans and David Newbold (DAQ) have also made suggestions with respect to the CE/DAQ interface (also attached). • The gist of their proposal is to come as close as possible to requiring that we send data (over fiber) that can be received by commercial DAQ hardware. On the other hand, the DAQ group expects to use some mix of FPGAs and GPUs to sort and compress data and to trigger. If their hardware includes FPGAs, they could certainly do all the data merging. • If the DAQ group insists on a “Quality of Service” requirement for our data packets, we would probably have to add a large memory to the object that merges data streams.

My bias with respect to where to merge data streams • I would like to retain the authority (within our consortium) to decide where our data streams are merged. • ProtoDUNE WIB merges 4 to 1 for output to FECs and 8 to 1 for output to FELIX. Data is output using UDP (with no provision for retries). • I am worried about adding off-FPGA memory to the WIB. • I think we may decide that we want to simplify the WIB operation & drive 1.2 Gbps links off the cryostat to the Central Utility Cavern. • This would minimize the digital activity on the WIB (which also filters power for the CE) and reduce the power consumption in the warm electronics crate. • In this case, we will need to include in our scope the fibers connecting the WIB to the CUC as well as the data-merging board (& its crate). • We might be able to merge many more than 16 data streams on a single pcb using inexpensive FPGAs.

My bias with respect to clock distribution and control • I think we should retain to option of configuring the FE ASIC differently for accelerator and non-accelerator data taking. • This would require a procedure to quickly reconfigure the FE ASICs. • It would also require that the local timing system maintain a copy of (relevant parts of) the FNAL accelerator time line. • I think this would be a DAQ responsibility. • I don’t think any long baseline neutrino experiment has done this before. • If all one wants to do is tag beam-related data, this is not required (only need a seconds-long buffer so signals from FNAL can be received). • The CE/DAQ interface document needs to say something about distribution of clocks and control information. • Calibration is also relevant, but I don’t know how this should be reflected in the interface document.