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'
Similarly:
D2+ = 2B&1A+
D2*+ = 2B*&1A+
Allowed characters
An L1 line name may contain any of the characters (see above).
[A-Za-z0-9'*+<=>]
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
|
