Project

General

Profile

July 2014 work items

These are some notes on the tasks that were discussed at the 15-Jul-2014 Mu2e DAQ meeting [notes initially written by Kurt, additions/corrections welcome].

Planned or desirable deliverables:
  1. By June 2015, have the 6-server pilot system up and running. This includes the following functionality:
    • one DTC per server
    • at least one artdaq EventBuilder process running on each server
    • how many real or simulated ROCs per DTC?
    • what data rates should be supported? Between ROCs and DTCs? Between DTCs and EventBuilders? To disk?
  2. By an undetermined date, be able to provide single-server test systems to subdetector groups for ROC development and testing or detector development and testing. Providing such a system does not necessarily imply buying or donating a computer or other hardware. Instead, the DAQ group could provide recommendations on the appropriate server(s), PCIe card(s), network switch(es), etc. that the subdetector group should purchase. It does imply providing the firmware and software that would be run to acquire and store the data. This could take the form of a set of instructions for fetching, installing, building, and running the software, or the DAQ group could choose to assist with some of those steps. The features that would be part of such a system would be the following:
    • how would configuration be handled?
    • what level of online monitoring would be included?
Software tasks:
  1. Tag and release the current mu2e-artdaq code [Ron]
  2. Update the mu2e-artdaq code to use the latest version (as of 15-Jul-2014) of artdaq [Ron]
  3. Split the mu2e-artdaq code into two packages, one with just the data format classes [Ron & Kurt]
    • the repository has already been created: mu2e-raw-data
  4. Investigate the use of JavaScript as a technology to use as part of providing tools in artdaq that facilitate debugging and testing hardware and firmware [Ron]
    • [Kurt] my understanding is that this will proceed in the background as time permits
  5. Develop a set of C++ classes and FHICL configuration files that demonstrate the reading of individual fragments from hardware (e.g. a DTC or a DTC connected to a real or simulated ROC) or a file. [Ron]
Hardware tasks:
  1. Develop the firmware to transfer data over the optical fiber to a real or simulated ROC. A first step in this may be to get this working in loop-back mode. (did I get this right?) [Rick]
  2. step 2 is a real (possibly) simulated ROC to at DTC (real ROC hardware or development board simulating a ROC)
    • the real ROC prototype will be back in a couple of weeks (from 29-Jul)
  3. step 3 would be two or more of these
  4. Tracker ROC work. This is outside the scope of the TDAQ subproject and should be paid for with Tracker funds. [Greg]
    • this is under negotiation as of 29-Jul (tracker funds may be hard to find)
Coordination (management) tasks:
  1. Meet with Rob K. and possibly others to further specify the plan for organizing Mu2e DAQ code, raw data classes, monitoring modules, and other code into packages (possibly separate git repositories and UPS products). Document the plan [Kurt]
  2. Meet with Rob K. and possibly others to further specify the plan for breaking data packets that are useful in the online (for efficient network transfers) into data objects that are desirable in the online and offline analysis modules (in art). Document the plan. [Kurt]
  3. Meet with Cosmic Ray Veto folks to further understand the needs of the CRV detector in terms of readout, triggering, and software filters. [Mark, Kurt, Ryan]
  4. Based on the discussion with CRV folks and others, document typical data taking and readout scenarios including sample data blocks at various points in the DAQ system, a description of how data blocks are uniquely identified and grouped together into "events", and the sequence of steps that are needed to select and write different types of "events" to disk. (Also, define what is meant by "event" in various contexts.) [TBD]
Controls tasks:
  1. Install EPICS on a Mu2e computer and document the steps that are needed to install, configure, control, and monitor typical slow controls entities. [IOCs, database, EPICS archive engine, C++/XDAQ or nodejs] [Summer student]
Data processing tasks:
  1. [under consideration] Contribute to the art modifications that will improve its abilities in an online context. [TBD]
Goals in the BOE documents:
  • Data acquistion
    • Implement firmware for DTC transmission of basic readout/data requests and receipt of data over optical links using simulated ROC; Implement initial Mu2e version of artdaq running on single DAQ server.
    • Implement firmware for PCIe interface running on DTC. Implement DTC in situ programming via PCIe; Implement software for communication between DAQ server and DTC over PCIe interface; Create timing system PCB design.
    • Implement firmware for DTC buffering and transfer of ROC data from single optical link to PCIe interface; Implement artdaq DTC board reader process; order Pilot system components.
  • Data processing
    • Implement initial Mu2e version of art framework. Begin OpenCL evaluation for filter applications.
    • Demonstrate operation of art framework running on single prototype DAQ server with simulated event data. Begin testing OpenCL for filter applications.
    • Demonstrate optimized tracking filter running under art framework on single DAQ server. Benchmark preliminary calorimeter filter. Evaluate options for FPGA data pre-processing (fix-float conversion, unpacking).
  • Controls and networking
    • Define interface functions and protocols for DCS channel on optical links. Define CANbus DCS functions. Define sub-project DCS requirements.
    • Define Control/Data and DCS/Management networks. Define DCS endpoint map. Begin implementation of ROC microcontroller DCS functions.
    • Implement ROC firmware download over DCS optical channel. Implement ROC CANbus interface and reset.