1. - L0DU - Monitoring issues L0 workshop – LHCb 10 January 2006 Hervé Chanal, Rémi Cornat, Emmanuel Delage, Olivier Deschamps, Julien Laubser, Magali Magne, Pascal Perret LPC-Clermont

2. Outline 1.L0DU architecture : brief reminder 2.Online monitoring during data taking 3.test & debug of the L0DU board 4.Configuring L0DU board

3. L0DU : remind of the flexible architecture 24 words available on the L0DU board 17 are used : 7 from L0Calo + 8 from L0Muon + 2 from Pile-Up Fields : value (E t /P t /Content/Multiplicity) / address / status / BCID /... Definition of L0Processor Data in EDMS 528259 e.g : Electron(Et), Photon(address), Muon1(Pt) + Muon2(Pt), Pi0(Et) - Photon(Et),... So far, only +/-/Id operators are foreseen More sophisticated operators could be implemented in L0DU board : i.e. LUT(adress) defining a sub-detector region or neighbourhood of an object,... So far, only >/</= comparators are implemented 1 - L0 Processor Data : 32 bits words sent by L0-processors to L0DU 2 - L0DU Elementary Data : L0PU field or result of an operation on L0PU fields 3 – Elementary Condition : Comparison of L0DU data with a threshold value

4. Configure & parametrize the L0DU algorithm e.g: electron channel is currently defined as: [Electron(Et)>2.4 GeV] & [SPD(mult) 5GeV] Dimuon channel is: [Muon1(Pt)+ Muon2(Pt)] >1.5 GeV] & [Total(Et)>5GeV] Some Elementary Conditions are common to several L0DU channels  Global Conditions i.e. : Total(Et)>5 GeV / SPD(mult)<280 / PU(mult)<112 Electron OR Photon OR Hadron OR... 4 – L0DU channels : One or several (AND’ed) elementary conditions 6 – L0DU decision : L0DU Channels OR’ed 5 – Downscaling : Validate Channel-YES at a given rate An ‘accept’ rate is associated to each L0DU channel (currently 0-100% - step 1%). Allow to keep 1MHz constant when luminosity drops along a FILL. A possible strategy : duplicate all channels : one ‘high threshold’ tuned for maximal luminosity (begin of Fill) & one ‘low threshold’ tuned for low luminosity (end of Fill) Beggining of fill : Accept rate 100% for ‘high threshold’ and 0% for ‘low threshold’ Decrease (increase) the rate of the ‘high (low)threshold’ channels during the fill

5. L0DU architecture Exemple : L0DU schematics for Electron_low and electon_high channels only Electron_lowElectron_high From Julien Laubser’s talk in december LHCb week

6. L0DU monitoring during data taking What quantities to be monitored during normal run ? Channels decision (counters) Channels firing (counters) Elem. Conditions (counters) Elem. Data (histograms) Final decision (counter) Error flags (counter)

7. L0DU Monitoring Counters : Global decision  1 2x7 channels (high/low e, γ, h, π°L, π°G, µ, µµ) ‘Fired’ and ‘Accept’ channels (before/after downscal.)  14 x2 2 x7 + 4 ‘global’ conditions  18 various error counters (BCID alignment)  ? (few)  ~ 50 counters Is it our job to monitor also the error bits (~20) sent by L0 processors ? Histograms 7 + 4 ‘global’ Elementary Data are used Et(e, γ, h, π°L, π°G), Pt(µ, µµ), Sum(Et), Spd(Mult), PU(peak2), PU(Mult)  11 x Nbins counters Do we want (can) monitor also the non-used data (addresses, µ 2, µ 3, PU(peak1 ), …) Monitoring the currently defined L0DU algorithm :

8. L0DU Monitoring possible strategy : Increment the counters during a given number N c of LHC ‘cycles’ (3564 BX ~ 90 µs) When reaching Nc ‘cycles’ the counter values are transfered to a buffer and the counters are reset during the 3µs gap in LHC train pattern Software read the buffer during the Nc ‘cycles’ period rough estimation : Assume software reading limitation is dominated by I2c rate between FPGA and CCPC  100 kb/s (standard mode I2c) Counter dynamics : < 3564 (12 bits) / cycle (conservative) FPGA ressources : Single 20 bit counter : 20 blocks/25564 ~ 0.08%. Linear in #bits ~ 50 counters can be read @ 100 kb/s within 100 cycles (9 ms) The required counter dynamics is 19 bit  ~ 4% of FPGA2 ressources With 1000 cycles the required counter dynamics is 22 bit  ~ 400 counters  50 counters + 11 x30 bins histograms  ~ 35 % of FPGA2 ressources

9. L0DU Monitoring Software post-treatment : PVSS software will : Accumulate the counters/histograms over a larger periods (few seconds ) Refresh display Provide statistical analysis : mean, rms, time evolution of counters, … Compare to reference histograms Provide diagnostic, generate alarms, run summary, … Software issues : Some monitoring devices (counters) will be implemented in L0DU FPGA soon Sofware interface under construction Better knowledge of required L0DU ressources and software limitations in few weeks Other software functionalities : Monitor internal and external (GPL board) test benches – perform test & debug Configure and parametrize the L0DU algorithm - Interface with conf/cond DB

10. Test & debug Check & debug the L0DU behaviour (links, data flow, …) use of the internal and external test benches test @ Lab, during installation and commissioning, in between fills, … inject known patterns and compare output with expectation  Some hardware tests already done on prototype w/ simple algorithms  Test using PVSS software to inject pattern and get output pattern under preparation (ready in couple of weeks) use of spy memories to monitor data e.g. : due to the limited size of the bus between FPGA-3 (data pre-treatment as muons ordering) and FPGA-2 (main algorithm) the whole data set will not be available at DAQ level (3 highest muons available)  see Julien’s talk tomorrow during the commisionning session of the L0 workshop LODU output monitoring DAQ output (L0DU-Block) compare with offline emulator normal data taking or random trigger (to test L0-no events) limited debuging. Can only indicates a bad behaviour  see talk about the new hardware-like emulator in monday T-Rec meeting

11. Configuring the L0DU board PVSS configuration software under development (part of monitoring soft.) Possibility to define/save/load configuration and parametrisation set-up Interface with conf/condDB Exemple of user interface pannel for the current L0DU algorithm: 11 Elementary Data 18 Elementary Conditions 14 channels  See Emmanuel’s talk tomorrow during the ECS session of the L0 workshop

12. Primary data (from L0Processors) L0DU Elementary data Operation on primary data Configuring the L0DU board

13. Conclusion Main functionalities of L0DU prototype validated in 2005 Monitoring and DAQ (interface with TELL1) on top of priority now Software interface under construction Channels decision and Elementary conditions monitoring + possibly elementary data histograming seems achievable Better understanding of ressources available for monitoring and software limitation in few weeks