Background Remediation workshop talk 1/13/99
January 13, 1999, Frederic Kral (LBL)
There is one Trigger talk at the January 13-15 Background Remediation workshop. This note attempts to answer all the pertinent questions regarding Trigger.
A brief Description of the Trigger can be found off the Trigger Operations page.
Trigger Electronics Location and Function
There is no "Trigger" detector.
All Trigger hardware is in the Electronics House, with the exception of on-detector IFR-Trigger electronics. We have dedicated digital optical links from the Drift Chamber endplate (thus Trigger bits are generated in the DCH front-end electronics) to
the Drift Chamber Trigger (the TSF boards). We also have digital connections between the Calorimeter UPCs (part of the EMC ROM) and the Calorimeter Trigger.
The trigger has two functions:
- to deliver the Level 1 hardware signal that initiates readout, and the analogous "signal" in Level 3 software filter and
- to contribute data as a DAQ system in Level 1 and similarly contributing data in Level 3.
Deadtime from FEE to ROM
There is *NO* deadtime incurred by Level 1 as a hardware path. That does not mean the deadtime is a small number. It is zero. The Level 1 Trigger resolves events that are as little as 1 microsecond apart. Any events that are closer, are read out
together by all the BaBar front-ends. Thus there is no deadtime. The Level 1 Trigger can generate Level 1 Accepts comfortably at 100 kHz. Choice of Trigger line definitions and Prescale factors will limit the Level 1 Accepts to any value the Experiment
can handle (10 kHz, 2 kHz, 30 Hz, whatever).
The other portions of Trigger *DO* incur deadtime, just like the five detector systems (SVT, DCH, DRC, EMC, IFR). All the five spigots of Level 1 Trigger data (TSF, BLT, PTD, EMT, GLT) that deliver data into the DataFlow stream can cause deadtime;
Likewise all the Level 3 filter and data transport functions are in the deadtime domain.
contains the note by Cathy Cretsinger that calculates the deadtime information and the caution that we lost 80 microseconds for each spigot since that note was written. It could be recovered should it be needed by a future DataFlow system that needs to
handle rates well above 2 kHz. In terms of front-end-to-ROM tranfers, there is no problem at 2 kHz, the deatimes are well under 1 percent.
Deadtime from FEX in ROM
We have not benchmarked the DataFlow code in the various Trigger ROMs. There is very little feature extraction in any of the Trigger ROMs. Some formatting occurs in TSF ROMs and more extensive formatting occurs in the EMT ROMs. If we have problems
initially, these can be optimized away since the functionality is so minimal.
The maximum event size is not reached during regular data taking in any of our boards. Only the TSF board has variable-length records and a maximum density event is about 5 kBytes -- such events with hits in all wires of the Drift Chamber cannot possibly
occur at some frequency if BaBar is to consider itself operational. The TSF boards can handle such maximum occupancy events. It only takes about 0.5 microseconds to process a Level 1 Accept in the DC Trigger and Global Trigger boards. This is well under
the former 2.2 microsecond command spacing.
Trigger calibration without beam proceeds in three ways, to be done during daily BaBar regular calibrations:
Hot channel lists will be generated by these regular calibrations. Digital playback in a minimal fashion (very quick) may be done before each run in addition to the daily extensive calibrations.
- DCH electronics to TSF readout
- EMC UPC digital playback to EMT readout
- Digital playback between all Level 1 boards (TSF, BLT, PTD, EMT, GLT)
Offline studies will provide constants for the TSF and EMT, probably rather rarely (once per week). Beam position changes of more than 0.5 millimeters means new constants for the PTD.
Occupancy and its effect on Trigger
Trigger algorithms are protected from occupancy in Level 1 by several safeguards.
To avoid degradation with inefficiencies or poisoining by background hits wiping out signal hits, there are other measures taken.
- Demand superlayer segments in the DCH, with at least 3/4 layers hit.
- Perform per-crystal energy cuts in the EMC, before making multi-crystal towers. Typical cuts are 5 MeV per crystal, before making sums that need to exceed about 120 MeV.
- EMC signals go through a Finite Impulse Response filter to separate signal from beam backgrounds. Tuned for the particular backgrounds condition present.
Simulation studies have found that the DC Trigger is very insensitive to occupancy. The EM Trigger does lose performance gradually with occupancy, most noteably in the Event Time jitter. However, EMC Trigger rates are relatively stable since hard
particles are the source of EMC triggers.
- Majority logic in TSF segment finding (3 of 4 layers)
- Majority logic in PT Discriminator (3 of 4 superlayers)
What about Jitter?
The Global Trigger has been optimized to reduce the bad effects of Event Time jitter in the SVT (hit poisoning). It needs to be tuned. The current simulation has not been tuned but we will tune it by the end of January release. A tuned GLT gives event
time jitters of about 200 nanoseconds, a factor of five less than the worst-case spec (1 microsecond). The 200 nanoseconds may be optimistic, but we should be well below 400 nanoseconds even under worst-case backgrounds.
The Drift Chamber Trigger is very insensitive to jitter due to occupancy. Main contribution is that real background tracks occur near a given event a fraction of the time. For example, with a rate of 10 kHz of A Tracks (long DCH tracks), 1 percent of
events have an extra track within 1 microsecond of the true Event time. This event time can thus be pulled by that track, especially if it is a two-prong event. B physics and other multihadronic physics is solid with respect to jitter - and this is the
physics that the SVT is after.
The Calorimeter Trigger jitter grows with occupancy. We have not explored the full capabilities to filter this out in the EM Trigger algorithm, the Finite Impulse Response filter. Note that for the SVT, all neutral triggers are irrelevant. Only when an
inefficiency in the DCH fails to fire the DC Trigger do we need small jitter from the EM Trigger.
Simple Offline code can detect out-of-bounds Event Times from the Level 1 Trigger, using the DCH data.
We have simulated very large background sets several times (1995 TDR, 1996 Trigger workshop, 1998 Level 3 Preliminary Design Review). We'll have a workshop between now and May (probably in March) to re-visit the backgrounds. Debates are still in progress
on whether we should consume the huge amounts of CPU and disk space required to re-do the Level 1 and Level 3 background simulations in the same amount of detail as previously.
The main conclusions are that triggers come from real particles in the DCH and EMC. We have trigger configurations that will keep the B physics and probably most tau and two-photon physics even under large (formerly called x10) background rates,
including the effects of overlaid occupancy and reduced DCH cell efficiency. There are many trigger configurations and prescales that will preserve physics in the face of beam backgrounds.
Using Trigger to Monitor Backgrounds
The use of Trigger to Monitor Backgrounds is not something that requires immediate attention. We have thought about a few scenarios, but each one can probably be best done with the detector systems themselves. The point is that Trigger requires the Front
Ends to be fully on, with full or nearly full signals (HV on in DCH) available.
If the DCH is up, then whether you monitor its occupancy with DCH or TSF (Trigger) data is not all that important. If the DCH is at low voltage, Trigger is useless as a monitor. If the EMC is up, then both EMC and EMT (Trigger) can be used to monitor
the rates. Trigger is not all that more helpful. Such monitoring by DC or EM Trigger does not require extra hardware.