180 likes | 307 Views
CSC L1 Trigger Status: Primitives + Sector Processor. Greg Rakness University of California, Los Angeles CMS L1 Trigger Meeting CERN 7 November 2006. YE2. YE3. YE1. ME4. ME3. ME2. ME1. DT-11. DT-10. MTCC Phase II summary:.
E N D
CSC L1 Trigger Status:Primitives + Sector Processor Greg Rakness University of California, Los Angeles CMS L1 Trigger Meeting CERN 7 November 2006 G. Rakness (UCLA)
YE2 YE3 YE1 ME4 ME3 ME2 ME1 DT-11 DT-10 MTCC Phase II summary: • CSC in global DAQ running during all of phase II, except when requested to be removed… • 36 chambers (full 60 slice in 3 stations) • (mostly) singles from any station • one run of coincidences per field level • bulk of CSC operation was by shift crew + experts on-call G. Rakness (UCLA)
CLCT TMB CCB DMB CSC Trigger In Peripheral Crate In counting house On Chamber Cathode Strip Front End Boards (CFEB) Trigger MotherBoard Muon Port Card Sector Processor MPC OPTICAL FE SP ALCT FE Local Charged Tracks (LCT) generated on chamber and in peripheral crate… MTCC trigger primitive = coincidence between Anode LCT (, bunch crossing) andCathode LCT (, pT) Wire LCT Card Anode Wire Front End Boards (AFEB) RAT RPC – ALCT Transition Board DAQ MotherBoard Clock Control Board G. Rakness (UCLA)
Synchronization taskforce CSC management has created a taskforce to understand the timing, develop and implement the synchronization procedures of the CSC L1 trigger… Task force leader = Jay Hauser (UCLA) • Important feedback loops touch many facets: • online shifters, on-call experts • local DAQ online/fast-offline Data Quality Monitoring • critical upgrade added Track Finder (SP) data to DQM • offline analysis G. Rakness (UCLA)
Some tasks performed… • ALCT mirror firmware downloaded correctly to station 3 • Trigger primitive settings chosen and constant for Phase II: • ALCT*CLCT coincidence • ALCT layer requirements: 2/6 pretrigger (determines timing), 4/6 pattern • CLCT layer requirements: 4/6 pretrigger, 1/6 pattern • ALCT thresholds/fine delays • software upgrade includes comparison of configuration parameters set on the hardware (read through VME) versus intended values in xml file (transparent to change to database) • Trigger primitive configuration downloading from proms after hard reset successfully tested • open trigger windows to catch data which we might have missed why would we have missed it? • Compare trigger data through DAQ path with that through TF data path • Local runs triggering on single chambers • Test runs with “theoretical” settings from cable lengths under investigation G. Rakness (UCLA)
ALCT fine delays Insert before/after picture from Paolo Bartalini’s DQM plots… G. Rakness (UCLA)
Fraction of matched LCTs at TF and DMB for all chambers combined for different MTCC runs 4 5 6 99.9% • End of phase I (end of August) • Beginning of phase II (Oct 9th, run 3793 is from Oct 14th) • Time-in SP (Oct 15th) and ALCT firmware updated (Oct 18th) • AFEB delay fixed & DDU firmware updated & TTC software updated (Oct 23rd) • LCT-L1A window widened (Oct 24th) • 1 run with old AFEB Delays only 3 ½ hours separates these runs 1 2 3 D. Matlock (UCLA) 3797 4026 3973 4186 4189 4129 2553 4218 4275 run number 3999 3793 3802 4065 4138 4188 4190 4244 4371 G. Rakness (UCLA)
Strip occupancy as expected ME3/2/27 ME3/2/28 ME3/2/29 ME2/2/28 ME2/2/27 ME2/2/28 ME2/2/29 ME1/3/27 ME1/3/28 ME1/3/29 G. Rakness (UCLA)
Data eff around ME2/2/28: OK ME3/2/27 ME3/2/28 ME3/2/29 ME2/2/28 ME2/2/27 ME2/2/28 ME2/2/29 ME1/3/27 ME1/3/28 ME1/3/29 G. Rakness (UCLA)
RPC pad bit multiplicity/time bin • When “should” RPC data arrive? It depends… • To resolve multi-hit ambiguities… before the drift-delay finishes • To use in CLCT pretrigger decisions… before the CLCT pretrigger arrives… Multiplicity “reasonable” for cosmics… This “looks like” RPC data • What is stuff at time bin 0? • It goes away when a cut is made on: • RPC pad bit multiplicity = 1 Drift delay finishes here RPC data may be arriving too late for CSC to use…? CLCT “pretrigger” arrives here G. Rakness (UCLA)
Key wiregroup (~) RPC bit=8 RPC bit=9 RPC bit=3 RPC bit=2 RPC bit=7 RPC bit=6 RPC bit=10 RPC bit=11 RPC bit=1 RPC bit=0 RPC bit=5 RPC bit=4 ½ - strip (~) RPC pad bit correlation with CSC position • RPC pad multiplicity = 1, LCT multiplicity = 1 • TMB quality > 13 (at least 5 hits on ½-strip pattern) Cuts: Clear correlation of RPC pad bit with CSC position… • Does not cover entire chamber (low wiregroups missing, ½ of middle wire groups) • Where is bit 10? • Edges covered by bit 3, 4, and 8 in a strange way… • Why are bits 8-11 mapped to a much larger area than bits 0-7? G. Rakness (UCLA)
Sector processor section… Slides from Dan Holmes University of Florida ( ) G. Rakness (UCLA)
TF recent news… • Overall TF has run stably in MTCC… • BGo controlled • once configured, TF is controlled entirely through the TTC distribution • 1 S-LINK • commissioned during MTCC; data has been reliably sent to global DAQ • 2 FMM responses • from the SP & the TF DDU. Genuine errors appear as they occur. • Two SPs; • Second SP tried out in TF crate 3/11/06 • used in trigger path; both SPs send requests to CCB01 path, all LCT rate unchanged • both SP data sets seen in DAQ path • some issues with data unpacking, being resolved… G. Rakness (UCLA)
TF recent news TF DDUhas run consistently during MTCC; • global DAQ get good trigger data • we see genuine errors when they come at the FMM. ...but: • we see “FEDbadCRC” read out by global DAQ once every ~400k events • CRC between DDU & SLINK sender card not consistent • suggested solution was to raise potential on 3.3V line (see on DDU a slightly low value). • done 3/11/06, await big stats run. (should come with the CSC DAQ rate test.) • CRC between SP & DDU not consistent • suggested SP f/w update of bit flip did not work • problem may be slightly more complex than thought but is is probably just a f/w solution G. Rakness (UCLA)
TF recent news • SP MS GMT GT trigger path • Sat 21st Oct; saw; • real muons coming from CSCs • making a track @ TF • MS with dummy LUTs passes them on to GMT • GMT GT • GT distributes trigger back to CSCs • latency difference for specific setups was 6bx, swallowed @ SP but would be better to do at GMT.. • 100% efficiency for SP tracks to triggers received • problems seen with GMT/GT + DT + CSC + global DAQ control, (Ivan’s talk?) • more work planned for this week. • BXA used • SP ‘Bunch Crossing Analyser’ turned on; it allows the SP to trigger using primitives that arrive 1 bx apart. Run on 2/11/06 • saw coincident trigger rate go up from ~43Hz to ~60Hz • trigger latency unchanged, ‘split trigger’ assigned to BX of first primitive. • in process of checking data, no problems seen yet.. G. Rakness (UCLA)
TF recent news • DT & CSC track finder primitive exchange • MTCC 1 we timed in incoming DT stubs • i.e. the CSC can trigger on the overlap region • saw some timing variation in DT stubs (even wrt DT trigger). Little data from MTCC2 as DT masked out MB 2/1 in Lorentz Angle studies. • Timing in CSC stubs DT-TF? • we have been sending stubs to DT whenever we have ME1(/3) running, regardless of trigger • Sat 21st; a few hours of effort in TTC triggered pattern injections a-la 904 studies. • more work planned for this week • I will not be here Friday but Frank can cover me to a good extent. • I think the work is basically on the DT side to time CSC primitives into their trigger but I have some suggestions of how CSC can help in the slides that follow G. Rakness (UCLA)
TF recent news • DT & CSC track finder primitive exchange I think I learnt from 904; now I see in SX5; • If nothing in the primitive paths changed since 904 then we can use the arrival of the DT stubs at the CSC TF to work out where in the DT path the CSC stubs should be arriving. • Guess is that maybe DT should try delaying their stubs by ~10bx ± 2 • Why not use this as a ball park figure, histogram DT overlap trigger rate @ CTC as a function of variations about it?? (brute method). delay CSC here 6bx CSC data timed CSC trigger timed delay DT here ~4 bx timed DT trigger DT data G. Rakness (UCLA)
TF recent news Some suggestions for what else the CSCs can do for you… • we can make a CSC trigger only on ME1/3 • HV solution; turn of 1/1 & 1/2 chambers & use ME1 singles • MPC solution; mask 1/3 chambers to MPC links with MPC CSR4==0x8BDB. Run TF ME1 singles • now you get a trigger every time you get a stub • DT & CSC trigger are in time at the CTC. • can DT read out a FIFO and spy on where the stubs are arriving relative to the trigger..? • we can play with the CTC trigger latency or to help search for the stubs.. • we can make pattern injections on BGos • very configurable • I really don’t favour this as I think we have seen that practically it is a time eater • timing paths to the two TF are different G. Rakness (UCLA)