RUN 2B TRIGGER MEETING MINUTES 13 February, 2003 News: Darien Wood ----- o MoU's - need to get these soon if you plan to spend money soon o 132 ns - Beams Division will do "no further work" on 132 ns option - ...but it's not excluded - no design changes b/c of this - SIFT chip replacement w/ TRIP chip: SVX problems . if SIFT not replaced --> SVXII (pipeline depth = 32) would limit L1 latency > could run in 396 ns mode? . SVXII seems to have some data readout problems > BX-number dependent pedestals (in both Si and CFT) > may want to replace w/ SIFT b/c of this > data should be available w/in a week or so > decision should be made in Mar/Apr o Schedule Statussing - this will be done monthly - expect it! L1Cal Simulation Update: Jovan Mitrevski ----------------------- o Sliding Window Algo's - Jet - EM: hadronic & spatial isolation - Tau: narrow jet o Jet Algorithm: 2,1,1 - improvement shown in summer ~unchanged o EM Trigger - Hadronic Isolation: Et(had)x8 < Et(EM) - EM Isolation: Et(EM-ring) < 5 GeV - Performance on Z-->ee (0.5 minbias) . Run IIb performs better than IIa . main gain seems to be from isolation cuts . electron shower < 0.2x0.2 - Drell-Yan (7.5 min-bias) . gain from new algo is less for single-e trigger . more gain for di-e trigger o First Look at Combining Triggers - WH-->evbb: Run IIa EM trigger often triggers on the b-jets - need to look at combined (jet OR em) trigger - combination of Run IIb (jet OR em) triggers performs better in eff vs rate than combination of Run IIa o MC - need Z-->ee w/ more min-bias - need new QCD: currently using p8 for this - mix extra min-bias w/ muon-trigger data (unbiased for L1Cal) . this should be pursued o Tau Trigger - make jet-shape cut --> need accurate modeling of jet shape - Use Et(2x2)/Et(4x4) as measure of jet shape - Results: H-->tautau . Tau algorithm performs better than Run IIb jet algo - Should also check Z-->tautau o Noise and the EM Trigger - Hadronic Isolation kills a lot of low-Pt electrons - Current Design: noise biased to positive values b/c of cutoff in ADF - Simulation of Low-Et signals . quantized to 0.25 GeV . can use a "discriminator" to set all Et's below a cut to zero > current ADF has this at Et=0 (i.e. all negative signals suppressed) > put this disc cut to something above the noise level > ==> less bias toward positive noise > ==> less dependence on N(min-bias) > several values of discrim setting studied as well as different hadronic isolation schemes - Discriminator setting of 0.5 GeV . low Et electron trigger eff loss becomes less - Effect on Tau Trigger . zeroing noise ==> narrower jets ==> less tau discrimination . discrim = 0.5 GeV: degradation is fairly small o To Do List - Study Signals from ADF - Discriminator/Noise studies - Global Sums: need ICR - ICR effects on sliding windows - Tau - Cal-Track - Trigger Menus L1Cal Trigger Terms: Hal Evans -------------------- o More details on the web - http://www.nevis.columbia.edu/~evans/l1cal/hardware/ trig_terms/trig_terms.html - first pass list of terms available there - comments/ideas *very* welcome o Limitations on New Ideas from System Architecture - mainly from data transfer mechanisms . note: there is a lot of data to move around on the TABs and GAB . chip size and trace routing sets limits on the number of physical lines that can be used - main limitations from . 25 line limit on SW chip to Global chip transfer on TABs . 48 signal limit on TAB to GAB transfer - what is sent on these lines can (should) be optimised . changes to firmware relatively easy . increasing the number of lines is *much* more difficult o Design is rapidly being set in stone - we should hear about any new ideas *soon* - Example new idea (from Rich) is appended to the end of these minutes - note: any new schemes should be justified by simulation Simulation Efforts: Mike Hildreth ------------------- o List of Samples we would like to generate w/ p13 - (see talk) - Signals . add HW --> bb tau v - Backgrounds . Min-Bias Sample: 0-bias data + min-bias MC overlay o Algorithm Development - L1CTT . impact param effic studies . as-built geometry will go in p15 > can patch p13 to get correct geom (on farms) o Event Generation - can probably do signal samples on CAB - background probably should be done on farm - could use help from the farms in submitting these jobs - should be ready to start in ~2 weeks Cal-Track Match Simulation: Erich Varnes --------------------------- o Sample: Single Tau-->Hadrons - use tsim_l1l2 (tracks) + tsim_l1cal2b (cal) o Correlation b/w Jet cluster and Track Sector quite good o Matching Scheme - CTT sector overlaps (physically) w/ Jet Cluster + "off-by-one" sector - no Pt thresholds applied yet o Matching Efficiency ~ 76% o Trigger Bits - 16 bits with all comb's of 4-L1CTT-thresh's vs 4-L1Cal-Thresh's - most entries end up in highest-CTT vs highest-L1Cal o H-->tautau - 94% have at least one CTT-Cal correlation ADF Simulation: Jiri Bystricky --------------- o Description of Simulation - pattern generator - filter (IIR) - sampler (ADC) - filter (FIR) = dig-filt + peak finder o Problem (from last time) - could not resolve peaks separated by <1/2 BC ==> only one peak found - New Algorithm: does this correctly o Saturation - 80 GeV pulse . does not saturate ADC . does saturate output of dig-filt - 400 GeV pulse . does saturate ADC ==> plateau of 6 values . dig-filter output shows peak at correct point Discussion after video cut off... o Given that we will probably run at 396 ns - does it make sense to use the peak finder at all? - something to think about... ------------------------------------------------------------------------ Date: Thu, 13 Feb 2003 14:29:25 -0600 From: Richard Partridge Subject: Passing cluster info to the Gab board To: d0-trigger2b@fnal.gov Cc: "'Andre S. Turcot'" There was some discussion at today's Run IIb trigger meeting regarding the data to be sent from the sliding window FPGA to the Tab Global FPGA as well as from the Tab board to the Gab board. (see Hal's talk at http://www.nevis.columbia.edu/~evans/l1cal/meetings/030213/evans.pdf). I would like to propose that in addition, information from the highest two ET clusters in each TAB to the GAB board. This would allow much greater flexibility in developing global trigger algorithms for L1 since you would have the calorimeter objects themselves, rather than just counts of such objects. Examples of triggers that could be formed from the cluster info include an HT trigger, a missing ET trigger based on clustered energy, and a trigger on the sum of energy in the two highest ET jets (as we have often used in simulations of the nunubb trigger). Below is a "strawman" proposal for the data to be passed within the TAB/GAB system to illustrate how this might be done. Sliding Window -> Tab Global FPGA --------------------------------- The present design calls for 25 12-bit lines per Sliding Window (SW) FPGA, including 4 spare lines. I propose to use 1 of these lines to carry the info from the highest two ET jet clusters in the 4x4 region covered by a SW FPGA. The following info would be provided for the object: ET (8 bits, 1 GeV lsb) Phi within sliding window (2 bits) Electron Flag (1 bit, set for jet clusters that have an electron object in their 2x2 ROI) Tau Flag (1 bit, set for jet clusters that are identified as tau candidates) TAB -> GAB ---------- The present design calls for 48 12-bit words per TAB board to be passed to the GAB board, including 5 spare words (Hal's slide shows 6, but that didn't seem to add up...). As above, I propose to use 2.5 of these words to carry the info from the highest two ET jet clusters among the 8 central and forward SW's. The cluster info from the two "far-forward" SW's at the largest rapidity would be ignored since most physics processes are not interested in triggers from this region (|eta|>3.2?). The following info would be provided for each object: ET (8 bits, 1 GeV lsb) Phi within sliding window (2 bits) ID of sliding window (3 bits, provides coarse eta information) Electron Flag (1 bit, set for jet clusters that have an electron object in their 2x2 ROI) Tau Flag (1 bit, set for jet clusters that are identified as tau candidates) Trigger Bits ------------ Some trigger and-or bits will be needed for the triggers formed above. Hal's draft and-or assignment has 10 bits assigned to jet quadrant/region triggers. Given the track-match capabilities in the 2b trigger, there isn't an obvious need for these bits. Thus, I would propose dedicating these 10 bits to cluster-based triggers. Latency ------- Some logic will be required to do the energy sorting. For the SW FPGA, my count was 29 additional energy comparisons would be required to find the highest energy cluster within the 4x4 region. I believe this is a relatively small number compared to the number of comparisions already being done by the jet-finding logic. For the Tab/Global FPGA, 28 energy comparisons are required to identify the 2 highest ET objects. The latency is slightly over 132 ns (13 clock cycles) since you have to de-serialize to do the muliplexing. However, it might be possible to do this in parallel with the tau ID calculation if the energies are sent out to the TAB/Global FPGA ahead of the tau ID bit so that the increase in latency would be negligible. While the global logic is not on the "critical path" for timing, it is probably still a good idea to minimize latency to make sure there is time to implement the desired algorithms on the GAB board. As Hal mentioned at today's meeting, now is the time to have a discussion on what data should be passed internally/externally. I believe that something along the lines of what is proposed above would significantly increase the flexibility of the L1Cal trigger. Of course, I may be missing something... Regards, Rich