Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Intern. region
Vertex Tracker
Drift chamber
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Naming of L1 Trigger Lines

Conclusions from a meeting held on April 14, 1999

Rainer Bartoldus, The Universtity of Iowa

Meeting held on: April 14, 1999, 10am - 12am, SLAC Group C conference room

Attended by: Rainer Bartoldus, Su Dong, Al Eisner, Fred Kral, Anders Ryd (on the phone).

The goal of this meeting was to establish naming conventions and rules for the L1 trigger lines and to define procedures of how to support or enforce them. One issue was also to find a way of how to make L1 line names persistent, such that their meaning doesn't change in time (which means between runs).

Many alternative approaches to the naming scheme have been discussed. Instead of recalling all arguments I will just list the conclusions we have come to. If there are comments on this proposal we can come back and discuss why a particular choice was favored. In the following I will itemize the various issues and mention any necessary changes. The discussion was based on the current trigger configuration (TrgConfig) file.

The TrgConfig File

The Level 1 lines are defined in the L1Lines section of the TrgConfig file, which is shown below. An L1 trigger line is defined in terms of a logical expression which specifies one or more cuts on GLT object counts.

L1Lines =

D2:        (nA >= 1 and nB >= 2)                 number= 1   priority= 320   prescale=1
D2*:       (nA >= 1 and nB* >= 1)                number= 2   priority= 260
D2*':      (nA >= 1 and nB* >= 1 and nA' >= 1)   number= 3   priority= 210
2A':       (nA >= 2 and nA' >= 2)                number= 4   priority= 340
3B&1B*:    (nB >= 3 and nB* >= 1)                number= 5   priority= 150
3B&1B*&2A: (nA >= 2 and nB >= 3 and nB* >= 1)    number= 6   priority= 220
3A:        (nA >= 3)                             number= 7   priority= 200
C2:        (nM >= 2)                             number= 8   priority= 120   pescale=1
1M*:       (nM* >= 1)                            number= 9   priority= 100
E&M**:     (nM* >= 1)                            number=10   priority=  90
3M:        (nM >= 3)                             number=11   priority= 140
2G:        (nG >= 2)                             number=12   priority=  80
1G*:       (nG* >= 1)                            number=13   priority=  82
2E:        (nE >= 2)                             number=14   priority= 350
D2&1M:     (nM >= 1 and nA >= 1 and nB >= 2)     number=15   priority= 250
D2*&1M:    (nM >= 1 and nA >= 1 and nB* >= 1)    number=16   priority= 270
D2*'&1M:   (nM >= 1 and nA >= 1 and nB* >= 1                            
            and nA' >= 1)                        number=17   priority= 190
3B1B*1M:   (nM >= 1 and nB >= 3 and nB* >= 1)    number=18   priority= 160
D2&1E:     (nE >= 1 and nA >=1 and nB >= 2)      number=29   priority= 360
C2&1B:     (nM >= 2 and nB >= 1)                 number=20   priority= 170
C2&1A:     (nM >= 2 and nA >= 1)                 number=21   priority= 270
2M*&1B:    (nM* >= 1 and nB >= 1)                number=22   priority= 180
C2&1A':    (nM >= 2 and nA >= 1 and nA' >= 1)    number=23   priority= 280
3M&1B:     (nM >= 3 and nB >= 1)                 number=24   priority= 240
3M&2B:     (nM >= 3 and nB >= 2)                 number=25   priority= 230
1B:        (nB >= 1)                             number=26   priority=  70
1A:        (nA >= 1)                             number=27   priority= 290
1A':       (nA >= 1 and nA' >= 1)                number=28   priority= 300
1M:        (nM >= 1)                             number=29   priority= 130
1G:        (nG >= 1)                             number=30   priority= 110
1E:        (nE >= 1)                             number=31   priority= 330
1Y:        (nY >= 1)                             number=32   priority=  60

The file above represents the current setup for the PRV0 run and will be changed according to the discussion below. Note that for PRV0 all 32 L1 lines were used for the GLT, while in real running only 24 GLT lines can be assigned.

Glt object names

The 17 GLT object counts are:

nU nG nG* nE nY nM nM* nEM nA nA* nB nB* nA' nAM nBM nA'M nBMX

This is the exact order in which they are defined in the GLT board. The order is reflected in the GltConfigTC.

The object nIFR will be renamed to nU.

Shorthand line names

In addition to line names derived from the logical expressions (like 2A&1B) it is possible to define shorthand names instead (like D2). The only motivation for this is to make line names which are built upon this name shorter (such as D2&1M). However, it is discouraged to do so where it is not necessary. No explicit constraint will be imposed on the length of names.

The historical name C2 (nM >= 2) will be changed to 2M.

Cuts using = or <

The implicit convention is that for some object Z the line name 2Z would mean (nZ >= 2). To indicate other relations, you would use = and < in the line name. For the object Z you might have:
2Z:  ( nZ >= 2 )
Z=2: ( nZ = 2 )
Z<2: ( nZ < 2 )

The TrgParser has to deal with < = > in identifiers.

The * objects

The specifier * indicates one pair of objects being back-to-back in the detector. So, M* means 2M back-to-back. Only one such * object (pair) is well defined. There is no point in calling a line 1M* nor 2M*.

The names 1M* (or even 2M*) will be changed to just M*

The line name A+

Since the objects A (a long track) and A' (a long track satisfying a momentum cut) are counted from different sources (BLT and PTD, respectively) it is not guaranteed that an A' always implies an A. The line name A+ is defined to fulfill both requirements.
A+: (nA >= 1 and nA' >= 1)

The * ' + specifiers

Since there is only a B* related to B and an A' related to A, the * and ' specifiers can used for the D2 line name in a unique way. In this way, one would define the shortcuts:
D2   = 2B&1A
D2'  = 2B&1A'
D2*  = B*&1A
D2*' = B*&1A'
D2+  = 2B&1A+
D2*+ = 2B*&1A+

Allowed characters

An L1 line name may contain any of the characters (see above).

Line parameters

The configuration file may contain more than 32 line definitions, but exactly 24 of them must be activated for the GLT. This is done by assigning a priority (line number) to them. The arbitrary numbered priority field will vanish in favor for an explicit line number. (The previous plan to automatically assign priorities based on the trigger width has been dropped.) The line definition will also contain a width and a delay to configure the GLT's trigger decision FPGA.

Persistency of Names

In the long run, there has to be a way to ensure that the meaning of an L1 line name, i.e. the logical expression it stands for, doesn't change. At the same time it is desirable to keep the entire information on the L1 lines in the configuration file. (It would be hard to understand the L3 configuration if the GLT cuts were not visible.) To meet both requirements, I proposed the following idea. In addition to the TrgConfig file(s) in the configuration database, a dictionary will be kept in the conditions database that keeps track of all line definitions that have ever been used. This dictionary will contain the line names and their corresponding logical expression, but not the parameters specifying its priority, latency and width.

Initially this log file would start with just the set defined in the TrgConfig file. Whenever a new configuration is to be entered in the configuration database, its consistency with previous definitions will be checked. In particular two things will will not be possible.

  • A line name that has already been defined cannot be re-used for a new expression.
  • An expression that already exists cannot be entered under a new name.
For example, once 2A&1B has been defined, you will not be able to redefine it as 1B&2A. In this way it will be possible, even if unused names have been removed from the TrgConfig file, to verify that they are not going to be re-used in a later version.

Each time a valid new name is entered it will be appended to the dictionary, which works much like an audit trail file.

Rainer Bartoldus, Last update: April 20, 1999