Silicon/Trigger party: ~ 60 showed up May 6th @ Ted’s place

Silicon/Trigger party: ~ 60 showed up May 6th @ Ted’s place Old High-lumi Default table

May 6th was also Larry’s B-day… and Vadim, Florencia, Ricardo… Q without A: what’s going on 9 months before May 6th?

Professor Dee’s speech on how to improve bandwidth for babies …

Trigger Issues at higher luminosity Ted Liu Fermilab CDF Elba June 03, 2006

Why higher luminosity?-- A story I learned in graduate school … • Long ago, a famous young HEP theoretical physicist kept having trouble finding a girl-friend for a long time … • He then complained about it to Hans Bethe • Hans’s advice: “Young man, if the cross section is so low, increase the luminosity !”

For HEP experimental physicists, this is easier said than done • Not only the luminosity has to be increased, but also thebandwidth … • from collision point all the way to PRL editors office … • Trigger is just part of this process Improving bandwidth Online Trigger/DAQ Offline computing detector Analysis/meetings PRL ~100s ns ~ µs to ~ms ~weeks ~ months … beam time and life time …

What is trigger business ?-- the more you learn, the less you know • Many aspects of trigger business • Is it about improving trigger bandwidth? Yes and No • Is it about improving signal purity? Yes and No • Is it about having more signal events on tape? Yes and No • Is it about reducing deadtime? Yes and No • Is it …? • To some extend, it is about dealing with our ignorance as we don’t know exactly how the background (or even signals) will look like … Online Trigger/DAQ Offline computing detector Analysis/meetings PRL ~100s ns ~ µs to ~ms ~weeks ~ months

Trigger Table Trigger Table: a trigger “menu” to configure the trigger system to • Select a list of physics triggers determined by L1/L2/L3 requirements • determines the physics we can do (hadron collider physics ~ trigger table) • In principle, a physics process trigger cross section, s = B (constant) • In reality, a given trigger cross section,s ~ A/L + B + CL + DL2 • CDF trigger table contains > ~ 50 L1 triggers, > ~100 L2 & L3 triggers… • Solution - relax the effective prescale in real time as luminosity falls • High Pt physics triggers less likely get prescaled + … Online Trigger/DAQ Offline computing detector Analysis/meetings PRL ~100s ns ~ µs to ~ms ~weeks ~ months

Trigger Table performance in the old days (July 04) Because of high deadtime, at luminosity above 90E30, we had to run with a special trigger table with a smaller set of triggers: the so called “high lumi table” … Rate back-pressured due to deadtime Taken July, 2004 @ ~90E30, deadtime > 20% with L1A ~ 28KHz

Trigger Table performance this year -- Table 3_09 (1st GUT), designed for 170E30 Dynamically enable high rate B triggers as luminosity falls (more bandwidth available at lower luminosity). High luminosity store 4590 Taken Jan. 13, 2006 * Significant trigger table performance optimization/improvements in the past year * Take advantage of: L2/SVT/EVB/L3 upgrade improvements @ deadtime average over typical store: ~ 5%

When the table is pushed to its limit… >170E30 Feb. 12th, 2006 Table 4_00 Initial lumi: 176E30 At Initial lumi: ~176E30 L2A: ~ 630Hz High deadtime > 20% L1A back-pressured

Busy deadtime wall rather sharp hard wall ~630Hz we will be a L2A limited experiment for long time to come … EVB upgrade helped us A LOT,still some room for improvement, but there is a limit (~< 1KHz). At higher luminosity, the available bandwidth could be smaller… the real problem is that L2A x-section grows too fast for many triggers …

L3A & data rate

What are those L2 triggers with fast growth term? • A few stand out, have highest rate at 176E30 • But there are MANY grow up very fast • Some of them are backup triggers, with high growth term by its very nature… they may look small now… but they will grow quickly at higher luminosity… This is the MAIN challenge at higher luminosity… for RunIIb table

L2 triggers with high growth term-- roughly in three categories . Track/mu related: e.g. CMX etc L2CAL related: e.g. MET+2JETs backups What can we do?

Online Trigger/DAQ Offline computing detector Analysis/meetings ~100s ns ~ µs to ~ms ~weeks ~ months … beam time and life time … May 12th Trigger Workshop • Bring physics group and trigger folks together • To prepare for higher luminosity running • We have done great in the past, but we have major challenges ahead of us! Improving bandwidth & physics sensitivity PRL

Official RunIIb triggers RunIIb waiting list Backup triggers New trigger ideas * w/ existing system * w/ new hardware improvements * optimizing in mid/low lumi Sensitivity vs Inst. Luminosity * background (trigger growth term) * purity * detector performance * systematics …. etc Known known Known unknown Unknown unknown…. System optimization and balance XFT upgrade as it is: L1&L2 Examples of possible new ideas: (not in particular order) SVT barrel pointer 3 Layer XFT + IMU SVT SVXonly for forward… SVT to improve high pt triggers…Bjets etc L1 Phi trigger … New L2 clustering… Jet/Met/Higgs-Mjet/Top-Mjet … New tau triggers at L2… … Physics Triggers vs hardware improvements-- initial discussions with Beate & others Preparing a good productive workshop takes tons of real work: in the past 2 months, we have had 4 meetings dedicated to preparing for this workshop. Details see web talks at: March 31, April 14th and April 28th TDWG meetings, and May 5th trigger hardware meeting.

Trigger WorkshopPart I&II Part I: General Issues • Overall Strategy: One table or two tables? (different implementation) • Study “Sensitivity vs inst. Luminosity”: for all important triggers • Backup triggers: what prescale/luminosity range …etc • Table Survey • Find solution for important triggers with high growth term • System level optimization/balance • ScalerMon optimization • …. add your items here. Part II: Brainstorm session • Encourage people to come up with new ideas (algorithm and hardware improvements) • Already have a good list of new ideas … need to select the most promising ones… • Bring physics and hardware people together To physics groups: this is your last chance that you may get help from hardware improvements… please help!

Goals for May 12th Trigger Workshop • The central goal of the workshop is to understand where we are with the trigger system right now (including upgrades already in the pipeline), and what other upgrades we might consider, in order to get us to where we want to be. The workshop is going to be physics driven. The RunIIb physics and trigger committee has already identified the highest priority physics triggers we should keep at high luminosity. Our goal is to make sure that we can actually keep these triggers running at the highest luminosity, and if possible, even improve their performance or develop new trigger strategies, while optimizing the middle and lower luminosity ranges for other physics. • We will hear from each physics group what "where we want to be" means - for example, where do you see trigger issues that could prevent you from getting to the search sensitivity that you would like with 4-8 /fb? And where do you see possible improvements that could even improve your search sensitivity? • The best example is the Higgs search. With the attention being focused on the light Higgs, how do we ensure that we have the best shot for a discovery at CDF?Our upgraded trigger system is much more flexible now than most people know. Where can trigger improvements help to really improve our Higgs sensitivity beyond what we have so far estimated?

Talks at the May 12th workshop Physics Background: • Introduction: Ted • Overview of Physics Triggers: Dave • Higgs: Tom Junk • SUSY/Other Exotics: Ming • B Physics@high lumi: Kevin Current Upgrade • XFT upgrade status: Nils • L2 XFT expected performance: Andrew • L2A bandwidth (EVB/L3): Markus • CSL/data logger: Frank • Offline computing: Rick Snider Possible Future Upgrade: (1) L2 Clustering • Current System: Monica • L2 Jet triggers: Mary • L2CAL hardware upgrade: Ted • New clustering algorithm: Gene • Higgs Physics motivations: Viktor (2) SVT & forward tracking improvements • Improving lifetime measurement: Marco • new SVT upgrade: Paola • SVT upgrade study: Laura • 3 Layer XFT+IMU: Ben • SVT barrel pointer: Jonathan (3) L1 phi trigger • Motivation & hardware: Matthew The workshop was very successful, have learned a lot!

Some examples/highlights from the Trigger Workshop -- just examples, not a summary. Details see web talk. . Track/mu related: e.g. CMX etc L2CAL related: e.g. MET+2JETs backups attack the problem at its root: L2CAL upgrade idea Rate estimate, Trigger survey & Sensitivity vs inst. Luminosity study XFT upgrade will help, The question is: by how much

CMX triggers at L2: gone wild Andrew Ivanov has been developing a macro tool to simulate XFT L2 stereo track 3d-reconstruction. He is doing studies for the CMX inclusive triggers at L2… in progress…

Backup triggers at higher luminosity • “Backup”: the name is misleading • It is not 2nd class citizen. It is as important as the main trigger, if not more. • By its very nature, it usually has large growth term • If we are not careful, can dominate the trigger rates at higher luminosity

The RunIIb Backup Trigger Problem Veronique Boisvert + Dave Waters overlap with mainline signal triggers ~ 10-20% • A small selection of existing top & electroweak backup triggers fills up spare bandwidth. • Some hard work required to figure out which of these we really need at high luminosity.

The Trigger Survey https://b0www.fnal.gov/internal/ops/trigger/vsorin/trigpathuserinfo.html • We’ve actually had a (surprisingly ?) good response : ~2/3 of non-B triggers. Some B triggers have been filled. • We are starting to mine the data  • Names attached to triggers - very useful ! • A few clear statements can be made about backup trigger requirements at high luminosity. • A large number of “unknowns”. But at least we can prioritise them by rate and seek to get the most important studies done first. • Please help us to finish the trigger survey! • Thanks to the survey contributors so far: • Kevin Pitts, Simone Donati, Anyes Taffard, Oscar Gonzalez, Mary Convery, Chris Hays, Andrew Hamilton, Robert Blair, Sasha Baroiant, Veronique Boisvert, Larry Nodulman, Beate Heinemann, Chris Neu, Tom Wright, Oliver Stelzer-Chilton, Jonathan Lewis, Jiyeon Han, Pasha Murat, Ambra Grisele, Mario Campanelli, Alberto Annovi, Andrei Loginov, Tara Shears, Andrea Bocci, Rolf Oldeman, Cheng-Ju Lin, Sarah Budd, Jonathan Efron, Aidan Robson, Sasha Pronko, Stefano Torre

Existing L2CAL has worked well in the past As luminosity increases, starts to show “pacman’s age” -- Each cluster starts with a seed tower -- All shoulder towers that form with the seed tower a contiguous region are added to the cluster -- The size of each cluster expands until no more shoulder towers adjacent to the cluster found… -- Seed selection algorithm “favors” lower phi and eta -- found cluster location is the seed location Can form large fake cluster(s) due to CAL occupancy at high lumi… First problem showed up with ROF (see TDWG talks at June 25, 05) Seed location is not necessarily the cluster center Does not calculate the MET/SUMET at L2, only use L1 MET/SUMET Raw trigger tower energy information not available to L2 CPU … For details on limitations, see TDWG talks on April 14th, 06, and June 25th, 05. Limitations of existing L2CAL

More than a year ago, it became clear that the L2 Jet trigger has a large growth term with luminosity. We knew it was due to activities in the Ring-Of-Fire. Early last summer, we learned that it was due to too many shoulders in the ROF to cause L2CAL finding large/huge fake clusters (hardware algorithm limitation) Once the shoulders are removed from ROF, the situation improved dramatically…(~ up to 100E30 back then) However, as luminosity went higher, the high growth term comes back again… A brief history of recent L2 Jet trigger-- the rise and fall, then rise …

Why L2 JETs trigger rates grow up so fast? This is at luminosity around 90-120E30 … Details see June 24, 2005 TDWG talks Ntow=70 ET=121 eta=18, phi=19 *

Example: L2 JET improvements by kill ROF JET40: Table 3_04 JET40: Table 3_02 JET90: Table 3_04 JET90: Table 3_02

An old slide from my June 24, 05 TDWG talk:JET trigger long term issues • L2 JETs should drop significantly by ROF removal so far, JET90 means ~ 90% junk at high luminosity (Junk Enhanced Trigger) • As luminosity increases, do we need to worry about the other region (plug)? What could happen at, say, L > 2E32? * if happens to plug, could “eat/swallow” central jets alive at L2 Do your study early, as long as we understand any potential problem early enough, we know we can take care of it !… We warned people last June… turns out it is true…

Where we are now (table 4_00)… example L2 Jet40 L2 Jet15_PS25 Takes off again w/ and w/o ROF L2 Jet90 (now driven by Jet20 at L1) L2 Jet60 Tip of iceberg?

Run IIb main Physics Triggers Was estimated 40 nb for JET90 at 300E30. likely higher Straw Table @ 3E32

Examples of other triggers using JET at L2 BJET15_D120_JET10_ETA1.8 CJET10_JET10_L1_MET25 (MET+2JET HIGGs trigger) CJET15_L1_BMU10_BSUR_TSU0 FOUR_JET15_SUMET175

Important MET/JET related triggers have high L2 growth terms at high luminosity with fake clusters … Large fake clusters will reduce eff for triggers require multi-jets (such as top_multi-jets) at higher luminosity Current MET threshold is already hurting HIGGs physics Need to improve tau triggers at L2 for HIGGs physics Can we improve isolation triggers at L2? The bandwidth we gain helps other triggers … Why we need to think about improving L2 clustering?

With Pulsar system, it is possible… Pulsar was designed as universal interface board To interface with DIRAC output (or DCAS input), just need a new mezzanine card design… The idea is to send all the raw 10-bit trigger tower energy (LSB: 0.125 GeV) information into L2 CPU via Pulsars, then let CPU do the actual clustering (“offline-like”)… Clustering much more robust against high occupancy (large fake clusters can be avoid easily) MET calculation can be done at L2 with 10-bit info. (currently directly from L1, based on only 8-bit info) Would be the first time making all trigger tower energy info available to L2 CPU: a big step forward for L2 triggering at CDF Is there an easy way to upgrade L2CAL?

Proposal for L2CAL upgrade • Goals • Significantly improve JET/MET trigger purity • Enhance Higgs/exotics search sensitivity… • How • Develop a parallel L2CAL path using Pulsars • Send raw full 10-bit resolution trigger tower energy information directly into L2 CPU • Do software clustering inside the CPU • Full resolution MET/SUMET at L2 • Commission done in pure parasitic mode L2CAL • Details see May 12th workshop talks. • This proposal will be reviewed by end of June, along • with a few other ideas. Review committee chair is Nigel. • Decision will be made by 4th of July.

“Young man, if cross section is so low, increase the luminosity” -- Hans Bethe • After ~ 20 years hard work by many great people, CDF as an experiment has just reached its peak performance… the best is yet to come ! • Triggering at ~300E30 will be still tough, but we can do it if we are willing to • Strategy to get there: • First push current table performance up to ~200E30 • Once XFT upgrade is done, can go beyond 200E30 with RunIIb triggers • L2CAL upgrade may take us beyond 250E30 • Reaching 300E30: may depend on how to handle backup triggers • Other possible improvements could allow us to further optimize physics triggers at different luminosities (see Alberto’s talk next, and trigger workshop talks) Please come to Trigger Mini-workshop tomorrow morning!

Trigger mini-workshop tomorrow: First, Larry will tell us the history of CDF trigger: how did we get here?

Trigger mini-workshop tomorrow: At the end, Luciano will tell us his new thoughts on RunIIb trigger table…

Agenda for trigger mini-workshop tomorrow (9am-noon) • Introduction Ted • Historical Perspective Larry • Muon Trigger Eric • SVT status and future Paola • Isolation Trigger: status and future Bob • OCD triggers at high lumi Regis • Exotics triggers at high lumi Ming • New thoughts on High Lumi Table Luciano • Discussion ALL

Backup materials • For those who are interested in the details of the May 12th trigger workshop, please look at web talk. • More will be discussed at tomorrow mini-workshop • Please respond to the Trigger Survey… you don’t have to be an trigger expert to do it ! As long as you are doing analysis, your comment will be useful to us. • The rest are some slides on technical details for L2CAL upgrade… from May 12th workshop.

Improving L2 ClusteringPaola & Ted --Trigger Workshop, May 12th, 2006 • Limitations of the existing L2CAL and how to improve it? • Is it possible? -- current L2 system is flexible enough • What’s involved at technical level? • Can we justify it? -- motivations • Summary

What’s involved?-- only CAL related shown: concept L2CAL L2 CPU L2 Pulsar crate 10 bits tower energy 288 LVDS cables L2 CPU for commission L2CAL Pulsar crate L1CAL (1) A copy of input signal (2) New mezzanine: 4 cable/card (3) 18 Pulsars/AUX with new input firmware (4) 6 Pulsar/AUX SLINK mergers (5) Some simple online code (6) New clustering algorithm code Only 8 bits tower energy used by L1CAL 10 bits tower energy Calorimeter

In principle, one could design a special splitter board. Or can use LVDS multi-drop property to get a copy: How to copy the input signal?-- for parasitic running, crucial for commissioning Pulsar mezzanine Receiver (no termination) DCAS receiver DIRAC driver 100 ohm DS90C031 Need to make longer LVDS cables Actual cabling needs to be clean: with help from JDL

Could use one small FPGA on mezzanine, to receive 4 cable inputs: 4 x 40 input signals (input is running at cdf clock). Simple firmware to push the data (40 bits wide) into Pulsar DataIO FPGA. How to have 4 cable inputs per mezzanine (w/ option to enable or disable termination) New mezzanine card design

Mezzanine card design concept 10bits x4 =40 @ cdfclk input data per cable EM HAD EM HAD Cost estimate: 72 needed ~ 100 < $300 per card (dominated by FPGA) < $30K for mezzanine ~2 weeks engineer time 25 AUX cards + long cables Total cost of the project: < ~ $50K Have just enough spare Pulsars to do this job Cable connector Pulsar side LVDS/TTL chips 40 FPGA JTAG Pulsar front panel Rack door

Pulsar Cluster(1 Pulsar: 4 mezzanine x 4 cable = 16) x 18 = 288 input cables total Pulsar Crate 1 Raw data size w/o suppression: 288x40/8 ~1.5KB per evt. With some overhead, < ~ 600 slink words maximum w/ suppression, data size should be much less. Pulsar x9 9 slink outputs 144 cables from DIRAC one 40-bit word/cable Pulsar Slink merger x6 Pulsar Crate 2 PC Pulsar x9 144 cables from DIRAC 9 slink outputs Latency after L1A: ~ 4 to10 us, range depends on detail implementation Note: unlike other L2 paths, CAL data already available at L2 input upon L1A

New Cabling at trigger room Possible new pulsar crate locations Above the racks L2 Decision crate L2 CAL crates L1CAL crates Not terminated on pulsar mezzanine Under the floor Commissioning can be done in pure parasitic mode, using the spare decision CPU, along with a copy of all other L2 data paths information

To do it right and fast (~ half year), need ~ 4 young people full timefor half year. Postdocs/students. New mezzanine card design/firmware: ~ 2 months work including design, PCB turn around time, firmware, and testing Pulsar DataIO input firmware: ~ 1-2 months work Online code: ~ 1-2 month work Clustering algorithm optimization: ~ 1-2 months work with the goal of < ~20-30 microseconds algorithm time on average… All can be done in parallel. The rest work is the actual commissioning… ALL can be done in pure parasitic mode, no down-time needed. This is my estimate, based on the experience in the past n years, assume ~ 4 good young people, FULL time for half year Manpower on hardware/software assumption: anyone interested contact us Mezzanine card design: Ted/Mircea (UC engineer), firmware: Marco Piendibene from Pisa Pulsar DataIO firmware: Marco Piendibene Online code and hardware testing: one Ph.D student (from Pisa or UC) Clustering algorithm optimization: one Ph.D student (from Pisa or UC) Overall: one ~postdoc level person to lead the project and overall commissioning What it takes?-- need a few good men/women

Pulsar based L2 system is more flexible than people know -- it is a LEGO game Perfect project to attract good new students and postdocs Have tons of experience on Pulsar hardware/firmware/online software/CPU software/commissioning. Many experts still around to help There are faster PCs out there now… (current one is > 2 years old) Pulsar can do pre-processing (ET sorting, thresholds, SUMET/MET…) if needed. Can do even more… hope there is no need. Will need to order more Pulsar AUX cards (simple PCB)… used for L2 decision upgrade, SVT upgrade, and XFT upgrade… Algorithm code performance is the key: work started! see Gene’s talk… If needed, some can be implemented in Pulsar firmware. Currently, entire L2 algorithm time is only < ~ 1 microsecond. If more performance is needed for clustering, can order faster PCs. we have just enough spare Pulsars for this job. keep this in mind: we may not be able to do all of the other new ideas ... unless we order more. Some comments on hardware/software/manpower

Silicon/Trigger party: ~ 60 showed up May 6th @ Ted’s place