weeks Philip Rodrigues Data flow working group meeting 5 June 2019 - PowerPoint PPT Presentation

Self-trigger plans for DAQ weeks Philip Rodrigues Data flow working group meeting 5 June 2019 1

Aims • Demonstrate something we can reasonably call a “TPC self - trigger” • Prototype components of the FD DAQ design • Measure resource requirements • DAQ weeks start in five days’ time: important to have a concrete plan in order to make the best use of the time • Today: discuss the “data flow” aspects of the system, rather than “physics” of trigger formation 2

System components (eventually) FELIX BR FELIX BR FELIX BR FELIX BR FELIX BR Hit-sending BR x10 x10 Trigger cand’te BR APA FELIX BR FELIX BR FELIX BR FELIX BR FELIX BR Hit-sending BR x10 x10 Module-level Trigger cand’te BR APA trigger BR Hit-finding FPGA Hit-sending BR Data flow orchestrator Trigger cand’te BR APA Possibly more APAs... 3

Done so far • FELIX BR produces hits continuously • Hits in hardware trigger windows make it to offline FELIX BR FELIX BR FELIX BR FELIX BR FELIX BR Hit-sending BR • Hit-sending BR exists: x10 x10 • Included in RC • Receives hits (via ptmp) from FELIX Trigger cand’te BR • Hits in trigger window sometimes APA make it to offline • When they do, they match up with FELIX BR FELIX BR FELIX BR FELIX BR data FELIX BR Hit-sending BR • Rawdecoder sometimes crashes x10 x10 • Trigger candidate BR prototypes Module-level exist Trigger cand’te BR APA trigger BR • Alessandro & Giovanna wrote a prototype that listens to timing board clock Hit-finding FPGA Hit-sending BR Data flow • David L is combining this with orchestrator listening to hits • TPSorted from Brett exists for aggregation Trigger cand’te BR APA 4

Suggested order of tests Start with TC BR issuing triggers (by sending TimingFragments to artdaq). Add MLT later 1. Check that hits make it into the TC BR 2. Make a random trigger in the TC BR. Test data flow. 3. Time- window the hits, with Brett’s TPWindow or otherwise 4. Very simple hit-dependent trigger (eg count nhits in a time window; make an nhits trigger (very large or very small) 5. Physics trigger (eg Easy horizontal muon trigger: at least N hits in every link in a small time window) Profit!!! Discussion on adding MLT on later slides 5

Characterization • Throughput, latency, CPU usage • Physics performance: compare to CRT, maybe 6

CPU Hit-finding tasks • Fix double hits • Time individual steps (pedestal finding, filtering, hit finding) • Make nice plots of the steps with real data • Run with Filiberto’s reordered frames and measure CPU usage • Finish rawdecoder • Stop saving triggered hits (technical reasons; hit-sending BR sends them anyway) 7

Hit-sending BR tasks • Use Brett’s TPReplay to “replay” dumped hits in dummy mode. Will be useful for testing without needing hardware. Will require a straightforward change to DAQInterface/RC • Understand why hits don’t always make it to offline (maybe they’ve fallen off the circular buffer?) From Pierre 8

Trigger candidate and MLT BR tasks • Define format for TC message (ptmp?) and fragment (probably the same; not required) • Don’t hardcode input BRs. See https://its.cern.ch/jira/browse/NP04DAQ-76 • Can we implement this in a way that facilitates standalone testing? • Order of moving from “just TC BR” to full system test. Rationales: TC BR ready before MLT ready before DFO; make incremental changes to maximally-functional system at each stage (easier debugging): 1. TC BR triggers readout by pushing TimingFragment 2. TC BR triggers readout by pushing TriggerDecisionFragment (or whatever name) 3. Add MLT. TC BR sends TC to MLT. MLT triggers readout by pushing TriggerDecisionFragment 4. Add DFO. MLT sends TD to DFO. DFO triggers readout 9

Other tasks • Talk to offline about possible changes: • Can they deal with an event without a TimingFragment? • Can we change the FELIX fragment format in a way which doesn’t break backwards compatibility? (This is what’s needed to get hits-in-the-trigger-window directly out of the FELIX BR. Not strictly necessary) • Do they care about new fragments like TC/TD? I expect not • Convergence/tidying of code/configs. See https://its.cern.ch/jira/browse/NP04DAQ-73 10