SLAC PEP-II
BABAR
SLAC<->RAL
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?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
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...)

TrgConfig and Level 1

Cathy Cretsinger, University of Pennsylvania

This document is aimed at helping to define an interface between TrgConfig and the L1 trigger (EMT + DCT + GLT + FCTS). At this stage, it reflects my attempts to understand what configuring L1 requires.

Contents:


What TrgConfig Is

Short answer: TrgConfig is a C++ object that forces trigger configuration to be consistent across all pieces of the trigger system.

Long answer: See Ed Frank's document on TrgConfig for the justification and for a discussion of L3 and OEP issues related to TrgConfig.


Task List

TrgConfig must control the configuration of all trigger levels. The L3 and OEP aspects have been addressed elsewhere. Here, our interest is in TrgConfig's interface to L1. The tasks to be accomplished are:

  • Match up trigger line numbers between GLT and FCTS to assure correct assignment of prescales.
  • Match trigger line numbers to names that are used to define L3 input lines; TrgConfig must supply the correct numbers to each TrgLogicGadget.
  • Define the L1 trigger lines in terms of L1 trigger objects.
  • Define the DCT and EMT primitives and rules for combining them into L1 objects.
  • Enforce the following rules that are relevant to L1:
    • Each active GLT/FCTS line must be used in at least one L3 input line.
    • Only GLT object counts for objects included in the L1 line def can be used in the LogicGadget.
    • Each L3 input line must gate at least one script.
  • Establish an interface to TrgConfig that works both with hardware and with simulation.

Priorities

Some of the above tasks are not necessary for a first implementation of TrgConfig. We should prove the principle, then worry about all the features. I suggest that the first implementation of TrgConfig should support only the following features:

  • Define the L1 trigger lines. To make a configuration interface that is compatible with GLT and FCTS hardware will most likely require substantial modifications to the L1 simulation code; limitations on available L1 manpower suggest that waiting for this could lead to substantial delays. The alternative is to have TrgConfig generate, from its input, a trgGLTrgDec.read file that the existing GLT/FCTS simulation (in trgDC) could read. This would be a temporary implementation but would not require very much help from L1 experts.
  • Define L3 input lines in terms of trigger lines by name. For the first version, I think it would be reasonable to confine L3 input lines to using only L1 output lines -- don't worry about TrgLogicGadget and GLT object counts at this stage. TrgConfig will be required to handle name-to-number matching and to provide a list of line numbers to each L3MInputLineGenerator.
In this first pass, we would not worry about things like EMT and PTD thresholds, which should in principle be configurable, or about how to specify versions of lookup tables that various pieces of L1 need (TSF, BLT, even GLT). Even without those things, I think we can demonstrate the key elements needed to ensure GLT-FCTS-L3 consistency.

Future L1-related developments for TrgConfig would include (in no particular order):

  • Support for use of GLT object counts in L3 input line definitions (TrgLogicGadget).
  • Enforcement of standards for valid configurations, some of which were mentioned above.
  • Configuration of EMT (PTD) energy (momentum) thresholds.
  • Configuration of angle cuts in GLT (described below).
  • Management of lookup tables and other configuration data needed by various pieces of L1 (listed below).

Elements of L1 Line Definitions

In order for TrgConfig to completely define an L1 line for GLT and FCTS, the following elements have to be provided:

Line name
This is a character string that suggests what the line does. Input to TrgConfig should be in terms of line names.

The line name is not actually used by the GLT or FCTS. Its significance is that a triggermeister has a much higher probability of selecting the right line by name than by number.

Line number
This is a number from 1-32 that designates a bit position in the 32-bit trigger word that is passed from GLT to FCTS and distributed by FCTS with the L1Accept. GLT will use bits 1-24 of the trigger word; the last 8 are reserved to FCTS.

The line number serves as the identifier of the line in GLT and FCTS. Because the GLT lines require that line number reflect priority, the user should not assign numbers; TrgConfig should do that.

NB: The present GLT plans call for GLT itself to assign the line numbers, based on the Priority of each line. This is unacceptable because TrgConfig has to be the authoritative source of all trigger information. If TrgConfig is not in control of line numbering in the GLT, it cannot guarantee that FCTS will get the proper prescale factors. Therefore, TrgConfig should include an algorithm that can compute the proper line numbering from the priorities of the lines; GLT should simply accept TrgConfig's ordering. Implementing a scheme whereby GLT and TrgConfig independently use the same algorithm to decide line numbers is more risky -- one has to make sure the algorithm is always the same!

List of Objects and Thresholds
For each of the 24 GLT lines, this is a list containing a CutValue and an OperationCode for each of the 17 GLT objects. The object types are fixed for purposes of TrgConfig, but GLT must receive explicit instructions on how to handle each object type in each of the 24 lines.

For the 8 FCTS auxiliary inputs, the definition is simply an indicator of the source. Sources of these inputs are not yet understood and are not included in simulation. This could turn out to be trivial (e.g., line 32 is always Lemo8, etc.), but it needs to be investigated.

Priority
For GLT lines, this is related to the jitter in the line (see Trigger Width, below). The highest priority line must be line 24; lowest priority, line 1. (Rumor has it that this may have been coded with reversed ordering; that needs to be checked.) This has to be used by TrgConfig to assign line numbers, and it must also be given to the GLT itself so that it can stretch and delay signals.

For FCTS auxiliary lines, this is meaningless. We can perhaps use priority(-1) to indicate that a line is an FCTS auxiliary line.

Trigger Width
For GLT lines, this is the jitter associated with the line and is used to delay and stretch signals. It is expressed as a 4-bit word in units of clock15 ticks. Priority can be derived by sorting the lines according to jitter width, with smallest jitter receiving highest priority. However, the ability to override this default behavior could be useful. For FCTS lines, this is meaningless, as FCTS does not do any timing adjustments. It simply takes the snapshot of 32 lines, applies prescales, and takes an OR.
Prescale
For each of the 32 lines, FCTS must know the correct prescale factor. The format for providing this information to FCTS is not yet known.

Survey of GLT Objects

The GLT counts 17 types of objects. The definition of each object count is provided below, with configurable parameters highlighted in RED. Note that, aside from the parameters indicated, the definitions of GLT objects should be regarded as fixed; changes would require reprogramming FPGAs and/or replacing hardware.

From EMT inputs, GLT produces the following object counts:

  • NM : Number of M clusters, with a minimum angle between clusters
  • NMs : Number of M clusters, with a larger minimum angle between clusters
  • NG : Number of G clusters, with a minimum angle between clusters
  • NGs : Number of G clusters, with a larger minimum angle between clusters
  • NE : Number of E clusters, with a minimum angle between clusters
  • NY : Number of Y clusters, with a minimum angle between clusters
The angle cuts may be chosen separately for each count. In the hardware, these angle cuts are implemented via lookup-tables; thus, changing the angle cut means in practice downloading a new table.

From DCT inputs, the GLT produces the following object counts:

  • NA : Number of A tracks, with a minimum angle between tracks
  • NAs : A tracks, with a larger minimum angle between tracks
  • NB : B tracks, with a minimum angle between tracks
  • NBs : B tracks, with a larger minimum angle between tracks
  • NAp : A' tracks, with a minimum angle between tracks
Again, the angle cut can be chosen separately for each object and implementation is via lookup tables.

Matching operations in the GLT produce the following (and only the following) object counts:

  • NEM : Largest number of M clusters found within D degrees of back-to-back with any one E cluster
  • NAM : Number of A tracks that had a matching M cluster in nearest N (2-6) EMT phi bins
  • NBM : Number of B tracks that had a matching M cluster in nearest N (2-6) EMT phi bins
  • NApM : Number of A' tracks that had a matching M cluster in nearest N (2-6) EMT phi bins
  • NBMX : number of M clusters, but any phi bin that has an X cluster NOT matched to a B track (nearest N (2-6) DCT phi bins) is vetoed.
Configurable parameter N may be chosen separately for each of the four cases. In hardware, it is the number of inputs to activate on an OR gate. Parameter D is handled similarly.

Finally, the IFR trigger provides directly to GLT:

  • NU : 3 bits of encoded information about tracks found by IFT. Cuts can be applied to this just as to the other 16 object counts. For the meaning of the 8 possible NU values, see the IFR-GLT interface document.
Nothing is configurable in the IFT.

CutValues and OperationCodes

In the hardware, each trigger line is defined by providing one (OperationCode, CutValue) pair for each of the 17 types of trigger objects. The value of trigger line is set to the logical AND of the results of the 17 operations. (Note that logical OR is not included in the present design, although FPGAs in the GLT can be reprogrammed to accommodate it. We should leave room in our design for this possibility.)

The CutValue is 3 bits, supporting values from 0-7. The OperationCode is 2 bits, signifying the following boolean operations to be performed on a given object count (Nobj):

Code Meaning
00 TRUE
01 Nobj .ge. CutValue
10 Nobj .eq. CutValue
11 Nobj .lt. CutValue

To configure the hardware, one must provide to the GLT all 17 (OperationCode, CutValue) pairs for each of the 24 lines. TrgConfig should be able to generate this from a "zero-suppressed" input - i.e., if an object type isn't specified, assume the OperationCode is 00. In the current simulation, this information, together with Priority and Prescale values, makes up the contents of the trgGLTrgDec.read file.


Input To TrgConfig for L1 Lines

The above suggests that ASCII input to TrgConfig for Trigger Line definitions might look like this (for some sample lines):
L1Line D2 { NA(ge, 1) AND NB(ge, 2)
prescale(1)
trigWidth(qqq)
prio(xxx)
}
L1Line C2 { NM(ge, 2)
prescale(1)
trigWidth(rrr)
prio(yyy)
}
L1Line 2M1A { NM(ge, 2) AND NA(ge, 1)
prescale(1)
trigWidth(sss)
prio(zzz)
}
L1Line C2PSS { NEM(ge, 1)
prescale(1)
trigWidth(ttt)
prio(www)
}
Some L3 input line definitions might then look like:
L3Input Open2 { C2 OR D2 }
L3Input Safe2 { 2M1A OR C2PSS }
L3Input LottaTrax { D2 AND NA(gt, 4) }

The syntax here vaguely resembles D0's trigparse utility and may not be what we want. The point is that all key components are present -- a definition in terms of object counts and cut values, a prescale value, a jitter width, and a priority.

Given such an input, TrgConfig must first properly order the lines and assign numbers. Then it must provide to GLT the full definition (OperationCode and CutValue for all 17 objects) of each line, along with its priority and width. It must provide to FCTS the prescale value to be associated with each line; if the mapping of the auxiliary FCTS lines to line numbers is non-trivial, it must provide that as well. Finally, it must provide correct line numbers to the L3 input-line mechanism.


Other Configurable Things in L1

Including most of these items in TrgConfig is not an immediate concern. However, all of the following are alleged to be configurable in L1, and some scheme for managing their configurations should be devised, with the goal of being able to reproduce a given configuration at a later date. Note that many of these things will change very slowly after an initial optimization period, and run-by-run configuration will probably not be required.

For the GLT:

  • ``DO_CUT'' logic defining the 24 trigger lines, as discussed above.
  • Delay of each input: A, B, A' tracks; M, G, E, X, Y clusters; IFR object count.
  • The D, N, and minimum angle parameters used in object counting, as described above. The angle parameters are implemented as lookup tables. N is a 3-bit integer for each of the four cases.
  • Priority and width for each GLT line, as discussed above. Note that priority can be deduced by arranging the lines according to width (which means that TrgConfig could be allowed to assign priorities), but the hardware does not prevent users from overriding this.
  • ``SVT Trick'' delay for each GLT line. This is used to impose the maximum acceptable delay at the final stage of generating the GLT output signal to FCTS.
  • Coarse and Fine global output delays. These two delays are imposed after all the timing alignments, etc, and before sending the 24 line values to FCTS; they are used to absorb any remaining latency in the L1 budget and to fine-tune timing between GLT and FCTS. In hardware, there is a single 13-bit delay word with bits 12-8 indicating the coarse delay and bits 7-0 indicating the fine delay.

For the EMT:

  • Cluster thresholds for M, G, E, X, Y
  • FIR filter constants, used to determine timing

For the DCT:

  • TSF
    • Look-up table defining segment properties
    • Wire map of hot wires (so they can be disabled)
  • BLT
    • Segment map for dead segments (so they can be enabled)
  • PTD
    • Pt threshold for accepting an A' track, implemented as a lookup table
    • Number of layers required (3/4 or 4/4)

What Is Not Understood

All of these issues have been mentioned elsewhere. They're grouped here for convenience, with links to where they were discussed:
Created by Cathy Cretsinger (cretsi@slac.stanford.edu)
Last updated 1 July 1998