D0 Run II Level 1 Trigger Framework Technical Design Report -------- Michigan State University Draft 5-JUNE-1998 Maris Abolins Daniel Edmunds Steve Gross Philippe Laurens Contents -------- 1. General 2. Concepts and Overview a. And-Or Input Terms b. Specific Trigger c. Geographic Section d. Readout from Level 1 Trigger Framework e. Accounting f. Specific Trigger Groupings 3. Physics input to the Level 1 Trigger Framework a. And-Or Input Terms b. Physics And-Or Input Term combination c. Programmable Bunch Select And-Or Terms d. No Direct-In Test Triggers e. What happens during the Super-Bunch gaps or mini gaps 4. Interface with the Data Acquisition System 5. Latency and Rates 6. Event Flow Control a. COOR Enable/disable: b. Geographic Section Busy c. External Sources of Disable d. Prescaler: e. Autodisable: 7. Event Identification a. Beam Crossing Number b. Level 1 Trigger Accept Number c. Level 3 Transport Number d. Absolute time / ACNET time 8. Trigger Information Output a. High speed outputs b. Level 1 Trigger Framework Data Block c. Serving Monitoring Data d. Begin/end Run Files 9. Test and Diagnostics a. Low level hardware tests b. High level verification c. TRGMON 10. Error Detection and Error Recovery a. Geographic Section Error b. Level 3 request for Initialization of Geographic Section c. And-Or Input FIFO error d. Connection to DZero Alarm System 11. Luminosity and Exposure Groups a. Scalers for Luminosity Measurement b. Exposure Groups c. Specific Trigger Luminosity Exposure 12. Trigger Control Computer a. TCC access to the Trigger hardware b. link to COOR c. Monitoring data server d. Alarms e. Diagnostics 13. What is missing from this document a. Lack of information b. Explicitely excluded 14. Known Limitations a. No OR-ing of And-Or Terms in Specific Trigger b. Less scalers in data block than for Run I c. Minimum previous/next information in data block 1. General This document describes the Level 1 Trigger Framework for Run II of the Fermilab Collider program. The similar system from Run I is described in D0 Notes #328 and #705. Many concepts used in the Run I Level 1 Trigger Framework have been brought forward into the Run II system. The Level 1 Trigger Framework implements one component of the Level 1 Trigger System for D-Zero. For a Global view of the Trigger and Acquisition system of D-Zero see the D-Zero Upgrade Technical Design Report. The Level 1 Trigger System is a hardware trigger system filtering the 7.59 MHz Beam Crossing rate with minimal Dead Time (less than 5% in normal desired running conditions). The Level 1 Trigger System consists of the Level 1 Trigger Framework and the Level 1 Trigger Subsystems (cf. Figure www.pa.msu.edu/hep/d0/ftp/l1/framework/drawings/run_2_blk_l1_fw_blk.gif). Each Level 1 Trigger Subsystem processes detector-specific information and produces, for every Beam Crossing, Input Terms to the Level 1 Trigger Framework. These And-Or Network Input Terms convey to the Framework a summary of the activity seen by the Level 1 Trigger Subsystem in its associated Detector component. Using these Framework Input Terms and other information about the readiness of the DAQ system to begin another acquisition cycle the Level 1 Trigger Framework determines for each Beam Crossing whether the resulting event should be rejected, or captured for further analysis in the Level 2 Trigger System. The desired rate for events selected by the Level 1 Trigger System is 10 kHz. The Level 1 Trigger decision for Run II is not made between Beam Crossings; it is however generated with a fixed latency. An important basic property of the beam delivered for Run II is that the Bunches of particles in the accelerator are spaced 7 RF buckets or 132 nsec apart. The Level 1 Trigger Framework can operate with or without the Bunches of particles divided by gaps into Super-Bunches. The Framework itself generates Input Terms that can be used to guarantee a minimum spacing between positive Level 1 Trigger Decision (called Level 1 Trigger Accept) or that no more than one Level 1 Accept is issued during a Super-Bunch. The Level 1 Trigger Framework is programmed and controlled by the Trigger Control Computer (TCC). TCC receives high level programming requests from COOR, the global coordinating program for the online operation of the DZero experiment, and performs the low level register programming operations required to implement COOR's requests. The Level 1 Trigger Framework was completely redesigned for Run II; it is built out of 9U 400mm cards in customized VME crates and makes extensive use of FPGA technology. All cards in the new Framework use the same general circuit board and the same front and rear panel layout and connectors. Conceptually this card is referred to in the documentation as THE-Card (cf. www.pa.msu.edu/hep/d0/ftp/l1/framework/hardware/the_card/ the_card_description.txt). The FPGA programming on this common platform produce the different functions needed throughout the system. Only five different physical implementation of THE-Card have been produced and they differ only in the routing of internal traces in what is referred to as the Main Signal Processing Array. The main differences between the Run I and Run II Trigger Frameworks are: - The decision is NOT made between Beam Crossings (now pipelined operation). - Ability to continue performing Level 1 decisions while a Level 2 (formerly called Level 1.5) decision is in progress. - Increased number of Level 1 Specific Triggers to 128 (from 32). - Increased number of Geographic Sections to 128 (from 32). - Improved monitoring of luminosity and exposure of each Specific Trigger to "live" Beam Crossings. 2. Concepts and Overview a. And-Or Input Terms Event information is fed to the Level 1 Trigger Framework through its And-Or Input Terms. There is a total of 256 And-Or Input Terms available. One And-Or Input Term is a binary signal that is captured by the Level 1 Trigger Framework on every Beam Crossing. It is a one-bit state which, for a given crossing, can be either asserted or negated. Level 1 Trigger Subsystems use And-Or Input Terms to pass their results to the Level 1 Trigger Framework. The And-Or Input Terms can also be used to bring information from other sources into the system; general beam condition indicators, or cosmic background veto signals are made available in this manner. Any other information or status of interest that can be represented with a one-bit binary state (e.g. Pulser On/Off, is this the 29th beam crossing in a turn, has it been at least X usec since the last L1 Accept) can use the And-Or Input Term mechanism to become part of the Level 1 Trigger decisions. The primary use of And-Or Input Terms is to bring in any physics indicator, any beam indicator, any background indicator, any environment information, and in general any event-dynamic (or static) information that is needed for sorting Beam Crossings and forming a Level 1 trigger decision. Since And-Or Input Term rates may be monitored they can also be used to monitor special signals (even if they are not used in any Level 1 Trigger decisions). Since And-Or Input Term states are captured for each event selected, they can also be used to capture binary information (even if it is not used in any trigger decision). The actual connection of And-Or Input Terms to the Trigger Framework is accomplished in groups of 16. A group of 16 And-Or Input Terms has an accompanying Gap and Strobe signals. The details about this electrical connection can be found in www.pa.msu.edu/hep/d0/ftp/l1/framework/ andor_terms/receiving_l1_framework_input_terms.txt. An explanation of how the Trigger Framework automatically synchronizes to the latency in the flow of a given set of 16 And-Or Input Terms is explained in www.pa.msu.edu/hep/ d0/ftp/l1/framework/hardware/trm/term_receiver_fpga_description.txt. b. Specific Trigger For every Beam Crossing 128 separate sets of And-Or Term combinations are evaluated. The result is used to produce 128 separate Level 1 Specific Trigger Decisions. The global Level 1 Trigger Decision is the logical .OR. of the 128 Specific Trigger Decisions. The global Level 1 Trigger Decision will be positive (called Level 1 Trigger Accept) for beam crossings where at least one of the 128 Specific Trigger Decisions is positive, and will be negative when all of the 64 Specific Trigger Decisions are negative. A Specific Trigger Decision is positive for a particular Beam Crossing when all its And-Or requirements are met, AND when additional conditions (the final specific trigger decision conditions) are met. The final specific trigger decision takes into consideration, among other things, the readiness of the DAQ system to begin another acquisition cycle. Before a Specific Trigger can fire, the rest of the DAQ system must be able to accept an event produced by the firing of this Specific Trigger. Each of the 128 Specific Triggers can be independently enabled or disabled by COOR at anytime. A Specific Trigger can also be prescaled. A more detailed explanation of prescaling is presented later. c. Geographic Section All parts of the D-zero Acquisition system that capture data in response to L1 Accepts and then forward this data to the Level 2 and/or Level 3 Trigger systems, are connected to the Level 1 Trigger Framework by a Serial Command Link. Each component of the Acquisition system that is connected to the Trigger Framework via a Serial Command Link is called a Geographic Section. During Run II D-Zero will allocate one Geographic Section for each VBD card (VBD = VME Buffer Driver; a card that collects data and sends it over the Data Cables to Level 3). The Serial Command Link (cf www.pa.msu.edu/hep/d0/ftp/scl/ scl_description.ps or http://daepc9.fnal.gov/d0docs ) is a two-way communication link where the Level 1 Trigger Framework tells the Geographic Section which Beam Crossings to capture (L1 Accept Signal), and where the Geographic Section tells the Level 1 Trigger Framework when it is not in a state to accept additional events (i.e. Geographic Section Busy or Error Signals). As explained in the Serial Command Link documents this control path carries a lot of information in addition to the items just mentioned, e.g. timing and Level 2 Decision information. The Level 1 Trigger Framework supports 128 Geographic Sections. Typical Geographic Sections are detector Front-Ends, but other subsystems also contribute data to the event. For example, the level 1 Trigger Framework uses a standard Geographic Section to control its own data readout. Another users of standard Geographic Sections are various components in the Level 2 Trigger system which need to know when to expect new Level 1 events and when to transfer the data that they generate up to the Level 3 system. Each Specific Trigger can be programmed to request the digitization and readout of any subset of the 128 Geographic Sections. While global data taking typically includes all parts of the acquisition system, partial detector tests benefit from partitioning the Data Acquisition system. A given Specific Trigger may require that only a specified fraction of the Geographic Sections be digitized while, at the same time, another Specific Trigger is collecting data from a different fraction of the Geographic Sections. d. Readout from Level 1 Trigger Framework The Level 1 Trigger Framework is a standard Geographic Section and contributes data to the event sent to the Level 3 Trigger for further selection. This information becomes part of the event data logged to tape. The event data read from the Level 1 Trigger Framework is called the Level 1 Trigger Framework Data Block and is described in the files you will find at: www.pa.msu.edu/hep/d0/ftp/l1/framework/hsro/. The Level 1 Trigger Framework Data Block captures all the inputs and outputs of the Level 1 Trigger Framework, along with some important intermediate results. A selection of scalers from the Level 1 Trigger Framework is also captured and included in the Framework Data Block. The Level 1 Trigger Framework uses the same VRB cards and their controller (VRB stands for VME Readout Buffer) as is used by the Central Detectors for readout in Run II. Drawings that show some of the details of the event data path out of the Trigger Framework can be found in the High Speed Readout section of: www.pa.msu.edu/hep/d0/l1/framework/ drawings.html. Less information is being readout from the Level 1 Trigger Framework for Run II than was readout during Run I. In particular fewer Scalers are being readout and not all data is systematically readout for the previous and next crossings (cf. the web location mentioned above and section 8 of this report). The size of the Trigger Framework Data Block in Run II is expected to be 2.7 kbytes. In Run I it was about 1.4 kbytes. e. Accounting Trigger operation must be properly accounted for. Appropriate scalers are included in the Level 1 Trigger Framework to perform this task. There are two main motives for keeping track of Trigger Framework operation. The first class is monitoring by the D-Zero operators and experts using host programs like TRGMON to insure its proper operation and normal data flow rates through the various stages of trigger and DAQ systems. The data obtained during this type of monitoring is only of temporary interest, but may occasionally be captured in log books. Trigger rates, dead time, etc are used to verify the proper operation of the system and when necessary to investigate and locate problems in the trigger and DAQ systems. In contrast, the second class of monitoring is for long term usage and is essential during physics analysis. While it might be consulted during the run, this type of data is destined to be permanently logged in databases. Luminosity and Specific Trigger Live Times are examples of this class of information. This data must be recorded at regular interval during every Physics run since the luminosity in the machine is changing with time. Much more information about this type of monitoring can be found in section 11 of this document and the web pages mentioned there. f. Specific Trigger Groupings In the Run II Trigger Framework there are a number of functions that consider the Specific Triggers in groups. Examples of this are the Exposure Groups, the L1 Trigger Qualifiers, and the diagnostic groups to study overlap in the firing of L1 Specific Triggers. The Exposure Groups are a new concept in the Run II Framework. They are necessary to allow detailed monitoring of the luminosity to which each Specific Trigger has been exposed during a run without requiring a prohibitively large number of scalers to accomplish this. The various sources of trigger disable signals that are correlated to the beam structure are collected together in what are called the eight Exposure Groups. Each Level 1 Specific Trigger is then programmed to belong to one of these Exposure Groups. Note that the Exposure Groups involve only the bunch correlated sources of trigger disable. This topic is covered in more detail in section 11 of this document. Providing Level 1 Trigger Qualifiers is another new concept in the Run II Framework. There are 16 L1 Trigger Qualifiers that are sent out over the Serial Command Link each time a L1 Accept is announced over this link. The L1 Qualifiers arrive at the Geographic Section in the same Serial Command Link packet that carries the L1 Accept message. A given L1 Qualifier is asserted during a L1 Accept message if any subset of the programmable group of Specific Triggers that are associated with that L1 Qualifier happened to fire for the beam crossing that caused that L1 Accept. The L1 Qualifiers provide a means of letting the Geographic Sections know if any Specific Trigger in a group of Specific Trigger actually fired during a particular L1 Accept. This is accomplished without shipping the entire 16 byte Specific Trigger Fired Mask out to the Geographic Sections. See the documents referenced on the web page www.pa.msu.edu/hep/d0/ftp/l1/framework/l1_qualifiers/ for more details about the L1 Qualifiers. An example of how L1 Qualifiers can be used is in the Level 2 Calorimeter Trigger. Not all events need to be searched for "low" Pt electrons in this L2 Trigger. All L1 Specific Triggers that require low Pt electron processing in Level 2 can be put together in a group that will cause L1 Qualifier number "N" to be asserted anytime any of them fire. Thus just by watching L1 Qualifier "N" the Level 2 Calorimeter Trigger can know whether or not it should spend the time to run its low Pt electron algorithm. In this example using the L1 Qualifiers also isolates the Level 2 Calorimeter Trigger from having to directly know which L1 Specific Trigger require the low Pt electron processing. Collecting Specific Triggers into groups for diagnostic purposes is another feature that was added to the Run II Framework. This is a programmable feature that does not interfere with the normal operation of the Specific Triggers. The principal use of these Specific Trigger Diagnostic Groups is to allow direct analysis of the overlap in firing of L1 Specific Triggers. There are 4 of these diagnostic groups. The programming of which Specific Trigger belong to which groups can be changed at anytime without interrupting the normal operation of the Trigger Framework. The output of each diagnostic group is connected to a scaler that increments only when all the Specific Triggers in that group fire on the same beam crossing. A similar new feature exists in the 4 diagnostic groups for the And-Or Input Terms. These 4 And-Or Term Diagnostic Groups are in addition to the normal 128 Specific Triggers. They allow one to study the rate at which a given group of And-Or Terms would fire if they were used in a Specific Trigger. The programming of which And-Or Terms are in which diagnostic groups can be changed at anytime without interfering with the normal operation of the Trigger Framework. Each And-Or Term Diagnostic Group has an associated scaler to show the firing rate of the "AND" of the And-Or Terms in that diagnostic group. 3. Physics input to the Level 1 Trigger Framework a. And-Or Input Terms The Level 1 Trigger Framework receives up to 256 And-Or Input Terms (cf. 2.a for general presentation of the And-Or Terms). The And-Or Input Terms must be delivered at the 132 ns Beam Crossing rate average. A FIFO input buffer allows the Level 1 Trigger Framework to de-skew different L1 systems that might have very different latencies. Along with their And-Or Input Terms the different L1 systems also provide their own strobe signal so that all systems are NOT required to bring their timing and cable delays in phase with a 132 ns clock provided by the Serial Command Link. The And-Or Input Terms are received in groups of 16, with each group carrying a Gap signal and a Strobe signal. The Gap signal is used by the Trigger Framework to verify that it is in bunch synchronization with the system that is the source of the group of 16 And-Or Input Terms. The Strobe signal is used by the Trigger Framework to control when it samples the state of the 16 And-Or Input Terms and the Gap signal. See www.pa.msu.edu/hep/d0/ftp/l1/framework/andor_terms/receiving_l1_framework _input_terms.txt for more details. The FIFO implemented in the And-Or Term Receiver Module has a maximum depth of 32 which more than covers the current planned Level 1 Trigger Subsystem latency of 25 * 132 ns (3.30 microseconds) measured at the Input to the Level 1 Trigger Framework. The Level 1 Trigger Framework will interrogate the And-Or Term Input FIFO's for a given Beam Crossing 3.36 microseconds after the Beam Crossing occurs as the first step in forming the Level 1 Trigger Decision for that beam crossing. A scaler is associated to each And-Or Input Term, and And-Or Term rates will be available to monitoring programs (e.g. TRGMON). b. Physics And-Or combination For each Specific Trigger a programmable combination of And-Or Input Terms is evaluated for each beam crossing and accounted for with scalers. For each Input Term a Specific Trigger can be programmed to either ignore the state of this particular Input Term, or include it in its requirements. When an Input Term is included in the programming of a given Specific Trigger it is specified either that the Input Term must be found asserted or that it must be found negated in order to satisfy the And-Or Network requirement for that Specific Trigger. The And-Or Input Terms involved in these combinations are typically "Physics Input Terms" i.e. Input Terms from the L1 Triggers. Later in the processing of each Specific Trigger the And-Or Fired signal for that Specific Trigger is "ANDed" with one of the 8 Exposure Group signals and other non bunch correlated sources of trigger disables before that Specific Trigger is allowed to fire. c. Programmable Bunch Select And-Or Terms The Level 1 Trigger Framework provides a mechanism to select a particular Bunch Crossing out of the 159 Bunches in the accelerator. Instead of allocating 159 out of the 256 And-Or Terms to implement this function, 8 special programmable And-Or Terms are allocated to allow the selection of a maximum of 8 arbitrarily chosen Bunches at any given time. These And-Or Terms must be setup in advance by providing the Trigger Control Computer with the location of the desired Bunch; the Bunch is specified by its delay in units of 132 ns from the Bunch P1 (e.g. P1 is 0, P2 is 1...). d. No Direct-In Test Triggers The Level 1 Trigger Framework will not provide for Run II the "Direct-In Test Trigger" service that it provided during run I. As a reminder, Direct-In Test Triggers were special And-Or Input Terms that were filtered by the Level 1 Trigger Framework and synchronized so as to be interpreted as asserted for only one Beam Crossing even if their actual duration of the signal sent to that Input Term was asserted for longer than the Beam Crossing Period (3.5 us during Run I). To achieve the same functionality during Run II, the user can connect to a standard And-Or Term and use the Autodisable feature (cf. 6.e.) of the Specific Triggers to guarantee that a single event is generated every time the And-Or Term is asserted. Another method to achieve the same single firing functionality is to use a Bunch Select And-Or Term in conjunction with a standard And-Or Input Term that would thus no longer need to be controlled with 132 ns precision. e. What happens during the Super-Bunch gaps or mini gaps As mentioned above the Beam provided by the Accelerator during Run II may be divided into Super-Bunches by gaps that will last a couple of usec. If we do not have these real gaps then we will periodically have a mini gap that will last for a beam crossing or two. In either case the Level 1 Trigger Framework requires that the And-Or Term Strobe is sent for all 159 beam crossings in an accelerator turn. The Serial Command Link that connects to each Geographic Section, including the L1 Triggers, includes a signal called the "Sync Gap" which will be asserted periodically either during a real gap or during a mini gap. When an L1 Trigger system prepares the results of its processing of data from a beam crossing for which the Sync Gap signal was asserted, then besides the Input Terms that it sends to the Trigger Framework, it asserts the "Gap" signal that is associated with the group of 16 Input Terms. The Trigger Framework knows when it is processing Input Terms that come from a beam crossing for which the Sync Gap signal was asserted. In this was the Trigger Framework can verify that it has not lost bunch synchronization with the systems that are sending Input Terms to it. 4. Interface with the Data Acquisition System The Level 1 Trigger Framework is connected to the rest of the Acquisition system by standardized communication links called the Serial Command Links. There is one Serial Command Link associated with each of the 128 Geographic Sections. A Serial Command Link is a synchronous serial connection with a protocol defining the exchange of bi-directional messages. Each Serial Command Link is associated with a Geographic Section and carries messages between that Geographic Section and both the Level 1 and Level 2 Trigger Frameworks. Messages from the Level 1 Framework are given priority for transport over the link. At their end of the Serial Command Link, the Level 1 and Level 2 Frameworks connect to it via the SCL Hub-End modules. At the Geographic Section end of each link there is an SCL mezzanine card which delivers the SCL data to the supporting circuit board. The main types of information transported over the Serial Command Link are summarized below. Information sent out from the SCL Hub-End: - Timing Information. (53 MHz clock, beam crossing clock, crossing counter, turn counter, live beam crossing indicator, gap indicator) - Results of Level 1 Trigger decisions. (L1 "accepts" along with their "L1 Trigger Number" and L1 Qualifier signals) - Results of Level 2 Trigger decisions. (L2 "accepts" and "rejects" along with their associated "L1 Trigger Number" and "L3 Transport Number" for L2 "accepts") - Initialize Geographic Sections (requested by COOR, or after a protocol error has been detected by a Geographic Section) Information received by the SCL Hub-End: - L1 Busy and L2 Busy (These signals indicate that the respective Geographic Section function is either busy or out of buffers and thus it can not process another "accept" message from the associated trigger level) - Error (Several rules can be checked at the Geographic Sections and buffer synchronization errors can be detected and signaled by the Geographic Sections. cf. 10.a) Fresh packets of SCL information are delivered to the receiving end of the Links every 132 nsec even if the Beam Crossing rate is ever switched from 132 ns to 396 nsec. Detailed information about the Serial Command Link can be found at: www.pa.msu.edu/hep/d0/ftp/scl/scl_description.ps or http://daepc9.fnal.gov/d0docs. The Trigger Framework has special hardware connections to the Level 3 System. For events that pass the Level 2 Trigger and are thus readout by Level 3 the Trigger Framework supplies Level 3 with the list of Specific Triggers that fired for this event and the Level 3 Transport number that was given to the Geographic Sections for use when moving this event up to Level 3. Level 3 sends a number of special signals to the Trigger Framework. These include a "Global Disable" of all L1 Specific Triggers and "Individual Disables" for each of the Specific Triggers. The Level 3 System uses these disable signals to stop the generation of additional events whenever it needs to drain the DAQ system to clear up a problem, e.g. a synchronization error with the transport of data to Level 3. 5. Latency and Rates As was the case during run I the time origin "T0" for Run II is the time when the beams cross at DZero coordinates 0,0,0. To simplify the descriptions time is frequently counted in ticks of 132 nsec. The Level 1 Trigger Framework will interrogate its And-Or Term Input FIFO's for a given Beam Crossing after tick 25 (3.30 microseconds after T0) to start forming the Level 1 Trigger Decision. All inputs to the Trigger Framework that are going to be used in forming the L1 decision for that beam crossing must have reached the Trigger Framework by that time. The Level 1 Trigger Framework will have formed its decision and delivered it to the Hub-End of the Serial Command Link by the end of tick 27. From there the information is sent out to the Geographic Sections. 6. Event Flow Control a. COOR Enable/disable Each of the 128 Specific Triggers can be independently enabled or disabled by COOR at any given time. b. Geographic Section Busy Before a Specific Trigger can be allowed to fire, the Acquisition system must be able to accept an event produced by this Specific Trigger. Each Geographic Section needs a mechanism to disable all Specific Triggers whose firing would result in that geographic section needing to accept and store another event. The L1 Busy signals from the Geographic Sections along with logic in the Level 1 Trigger Framework provide this functionality. This results in Specific Triggers being allowed to fire, i.e. being Exposed, only for beam crossings where the DAQ system can actually capture another event. Different Geographic Section can advertize themselves as being L1 Busy at different times, and for different reasons. A common reason why a Front-End may need to stop additional L1 Accepts is when it has run out of buffers to store more events. For the Level 2 Trigger that might mean that no processing node is available to hold and process the data from another Level 1 Accept. Another reason a Geographic Section may need to assert its L1 Busy signal is to protect its Front-End information during a window vulnerable to data capture or data management (e.g. right after a Level 1 Trigger Accept). After every L1 Accept, the L1 Trigger Framework disables itself for one or more ticks (the number of ticks is programmable via COOR). This guarantees the Geographic Sections time to return their L1 Busy signals to the L1 Trigger Framework. The Geographic Sections communicate their availability to the Level 1 Trigger Framework using the L1 Busy signal on their Serial Command link (cf. paragraph 4 above). c. Other External Sources of Disable Other external systems (e.g. Level 2 Trigger Framework, Level 3) may either disable individual L1 Specific Triggers, or globally disable ALL L1 Specific Triggers, using real-time hardware inputs provided. For example, the Level 3 system may need to disable some or all of the Specific Triggers while it gets ready to start a run, or when it needs to clear Data Cable readout errors. The Level 3 Trigger does not need to explicitly stop the flow of events from Level 1 when the Level 3 system runs out of resources since events will just backup in the Geographic Section's buffers, and the Geographic Sections already know how to handle this situation. d. Prescaler: When the And-Or requirements chosen for a particular Specific Trigger are not restrictive enough, the And-Or requirements may be met at a rate higher than the available event readout bandwidth, or simply higher than desired. To address this problem the Specific Trigger can be prescaled. This prescaling is performed in a way that is de-correlated with the bunch structure, using a duty-cycle prescaler based on a programmable circular shift register. This shift register is 64 bits long (this length is relatively prime to 159, the number of bunches in the accelerator). By programming this shift register with a pattern of 1's and 0's, prescale ratios in the set: { 0/64, 1/64, 2/64, ..., 63/64, 64/64 } can be selected. Prescale ratios smaller than 1/64 are also required. These are achieved by following the circular shift register with a 24-bit divide-by-N counter "afterburner." The shift register is programmed for a base prescale ratio of 1/64, while the "afterburner" divides this rate down further, to provide prescale ratios in the set: { 1/128, 1/256, 1/320, ..., 1/(64*2^24) Using a 24-bit divide-by-N counter, a Specific Trigger firing at the beam rate of 7.59 MHz can be reduced to firing once per 2 minutes. Note that the divide-by-N counter may only be programmed with values that are relatively prime to 159, to avoid correlating the prescaler with the bunch structure. This requirement does not unduly reduce the usability of the prescaler. e. Autodisable: Any Specific Trigger may be programmed to use this particular mode of operation where it automatically disables itself immediately after it has fired. The Specific Trigger must then be explicitly re-enabled with a request to the Trigger Control Computer before it has the possibility to fire again. 7. Event Identification a. Beam Crossing Number Each event collected in Run II will be stamped in the Trigger Framework Data Block with a Beam Crossing Number to uniquely identify the exact Beam Crossing from which the event was captured. The Beam Crossing Number is made of two parts. The first part is the 40 bit Turn Number counting the number of times that the P1 proton Bunch has crossed the DZero location since the last time the Trigger Framework was initialized. The Turn Number increments whether or not there is beam in the machine. The second part of the Beam Crossing Number is the 8 bit Crossing ID which specifies the position of the Beam Crossing within the turn. This Crossing ID is the time delay in units of 132 ns from the Bunch P1 (e.g. P1 has Crossing ID 1, P2 is 1,...). The Geographic sections are sent, over the Serial Command Link, the lower 16 bits of the Turn Number and the Crossing ID. In the Geographic Sections this gives each crossing an identification that is guaranteed to be unique for a period of about 1.3 seconds. Note that the Beam Crossing Number, in this Turn Number together with Crossing ID format, occurs in two contexts on the Serial Command Link. Each Serial Command Link is continuously telling its Geographic Section the Turn Number and Crossing ID of the Beam Crossing currently taking place in the D-Zero Detector. In addition the Serial Command tells the Geographic Section the Beam Crossing Number of the beam crossing for which the L1 Decision or the L2 Decision is being advertized in this SCL Packet. The Geographic Sections use the Turn Number together with Crossing ID of the event as the "Geographic Section L1 Trigger Number". This number is used to identify the event in all their data management tasks. All messages on the Serial Command Link will refer to the event by its Geographic Section L1 Trigger Number. b. Level 1 Trigger Accept Number Each Event is also tagged by the Level 1 Trigger Framework with the 40 bit Level 1 Trigger Accept Number. This number is incremented after every Level 1 Trigger Accept. The Level 1 Trigger Accept Number does not appear on the Serial Command Link; it appears only in the Data Block from the Level 1 Trigger Framework. c. Level 3 Transport Number To help control their transport over the network from the Front-Ends to the Level 3 System, events that pass Level 2 are assigned a 16 bit Level 3 Transport number by the Trigger Framework. This number is distributed over the Serial Command Link as part of L2 Accept messages. This 16 bit number increments only with every Level 2 Accept. d. Absolute time / ACNET time As in Run 1, the events need to be stamped with an accurate absolute time stamp that matches the ACNET time. Although it is not yet understood how this will be done in Run II, the desire is to stamp the event with the absolute time at which the L1 Accept was issued. This accurate absolute time stamp allows events in the data stream to be aligned with entries in the monitor-alarm stream. 8. Trigger Information Output a. High speed outputs High speed outputs are available from the Level 1 Trigger Framework. The Level 1 Trigger Framework provides Specific Trigger Fired Information to the Level 2 Triggers, to the Level 2 Trigger Framework, and to the Level 3 Trigger. The method for transporting the L1 Specific Triggers Fired List is still being studied. The 16 Level 1 Trigger Accept Qualifiers form another type of high speed, specialized information output. The Level 1 Trigger Accept Qualifiers define up to 16 independent groups of Specific Triggers. For each Level 1 Trigger Accept Qualifier a programmable arbitrary list of Specific Triggers is specified: the corresponding Level 1 Trigger Accept Qualifier signal is asserted when at least one of Specific Trigger in the list has fired. The signal is transported on the Serial Command link along with the L1 Accept message being sent to all 128 Geographic Section (i.e. 27x132ns after the Beam Crossing actually occurred inside the detector). cf http://d0server1.fnal.gov/electronicscer/scl_description.ps b. Level 1 Trigger Framework Data Block The Level 1 Trigger Framework behaves as a standard Geographic Section and contributes data to the event sent to the Level 3 Trigger. This information may be used to form the Level 3 Trigger Decision and becomes part of the event data logged to tape. This data is NOT sent to the Level 2 Trigger. The Level 1 Trigger Framework Data Block is outlined in http://www.pa.msu.edu/hep/d0/ftp/l1/framework/hsro/high_speed_readout_ data_block.txt. The Level 1 Trigger Framework Data Block is systematically present with every event recorded at DZero. The information captured can be classified in the following categories: - all inputs and outputs of the Level 1 Trigger Framework - some important intermediate results - some of the Global scalers and Specific Trigger scalers - Beam Crossing and Event Identification numbers - Time stamp All of the information in the L1 Trigger Framework Data Block is captured for the Beam Crossing that caused the event. All of this information is contemporary. Additionally, some important input information is also captured for the Beam Crossing directly preceding and the Beam Crossing directly following the event (in particular the state of the And-Or Input Terms). Less information is being readout for Run II than for Run I: fewer Scalers are being readout and not all data is systematically readout for the previous crossing. Another major difference is that the Level 1 Trigger Framework Data block is now separate from the Level 1.5 (now called Level 2) Trigger Framework, and the Level 1 Calorimeter Trigger data readout. The Level 1 Trigger Framework Data Block is used for several purposes. The Level 3 Trigger may need to access some information to help event filtering (for example read the state of some And-Or Input Terms for the current or previous crossing). The L1 Trigger Framework Data Block information may also be used offline during physics analysis. The Level 1 Trigger Simulator needs to access the L1 Trigger Data Block and read the inputs to the Framework to be able to recreate the Trigger Decision for verification purposes, or, to create different programming conditions, for Trigger studies. The Level 1 Trigger Framework Data Block is also used for for tests and problem diagnosis. Finally, the Level 1 Trigger Framework Data Block is part of the monitoring information served by the Trigger Control Computer and used by host programs like TRGMON. While the Trigger Control Computer cannot directly access the data readout stream, TCC can ask the Level 1 Trigger Framework hardware for a copy of the Level 1 Trigger Framework Data Block for the next event being captured and then access that copy. When the offline user wants to access information recorded in the Level 1 Trigger Framework Data Block they should look for the appropriate data extraction and access routine, or inquire about creating new routines to fill a particular need. Using the supplied access routines isolates the user from changes in the underlying format of the L1 Trigger Data Block. c. Serving Monitoring Data The Trigger Control Computer (TCC) gathers monitoring data and can serve monitoring information to remote programs. The data is collected at regular intervals (5 seconds) by reading registers in the Level 1 Trigger Framework. Note that TCC is also controlling the Level 1 Calorimeter Trigger and the Level 2 Trigger Framework, and collects monitoring information from these sources too. TCC also collects and serves monitoring information from the Level 2 Alpha Processor Crates under its supervision. Several clients request monitoring information from the Trigger Control Computer. TRGMON is the primary client for monitoring information. TRGMON formats and displays all the monitoring information available from TCC, including the Level 1 Trigger Framework, the Level 1 Calorimeter Trigger, and the Level 2 Trigger Framework. TRGMON is used as a general purpose monitoring tool to follow the operation of the hardware triggers and the data acquisition system. is also used by the experts to locate and diagnose problems. GM_SERVER is another client. The GM_SERVER process is a component of the Global Monitoring service that services all the components of the DZero acquisition system. The GM_SERVER collects information from a number of sources, including TCC, and a GM_CLIENT can fetch and display this information in the DZero Control Room. A new service needs to be established during run II to properly manage the luminosity information. The high luminosities of Run II will be accompanied with a profile where luminosity falls steeply as a function of time. We will have shorter and more frequent stores. During Run I, each run was taken at a (somewhat) constant luminosity, and with a constant set of Specific Trigger Prescale Ratios. During Run II recording information at the beginning and end of each run will not be sufficient. Luminosity and Specific Trigger exposition information will need to be captured and recorded at frequent and regular intervals. An improved luminosity service needs to be established to read information from the Trigger Control Computer and log the data for each run in a luminosity database. cf. section 11 and http://www.pa.msu.edu:80/hep/d0/ftp/l1/framework/ exposure_groups/measuring_luminosity_online.txt for a detailed view of the challenges associated with online luminosity measurement. Another luminosity service program (called PER_BUNCH_LUM during run I; by Dan Owen) read Per Bunch Scaler information from TCC to compute the instantaneous luminosity delivered at DZero, and writes a number of related quantities to ACNET. This service will also have to be filled by the luminosity database manager program. d. Begin/end Run Files Upon request from COOR the Trigger Control Computer can capture all the scaler information of the Level 1 Trigger Framework and write a file on the host computer as a human readable dump in RCP format of all the current scaler counts. These files are requested at the begin and end of runs, at the begin and end of stores, and during runs at times when COOR needs to pause and then resume data taking. The generic name for these files is Begin/End Run Files. All scalers are systematically captured and dumped in the Begin/End Run Files, along with the current set of Specific Trigger Prescale Ratios. Not all these quantities are used but they are still always available to run analysis programs. In particular the Luminosity Server program uses these files for computing and logging luminosity and live time. 9. Test and Diagnostics a. Low level hardware tests The Trigger Control Computer offers a high level interface with COOR to program the system, but it also offers an additional menu of lower level and specialized commands for detail access of the trigger hardware by the trigger specialists. The Trigger Control Software also includes complex programs that can test components of the system in situ. Specialized software exercises the whole system offline by providing test data input (e.g. And-or Input Terms) and comparing the hardware answer and outputs to the expected values. cf. http://www.pa.msu.edu:80/hep/d0/ftp/tcc/testing/testing_strategy.txt for details on Hardware testing, commissioning, exercising, and debugging. b. High level verification A verification program (called L1_COMPARE during Run I; by Jill Perkins) runs on the host computer and accesses a subset of the data from the event stream, along with the corresponding programming requirements. This verification program uses the Trigger Simulator program to produce a simulated trigger output and compares it to the results from the hardware. This verification cannot cover the complete Level 1 Trigger Framework output as some information is out of reach and control of the verification program, but is a very powerful tool to check that the hardware is performing as it was designed. It is also an important tool to catch problems as early as possible, and thus prevent a large amount of data from being affected by undetected problems. c. TRGMON TRGMON is the Trigger Monitoring Program, but is also an important routine checking tool which captures the global operation of the system and can give a high level view of anomalies. It is also a convenient diagnosis tool to locate problems. 10. Error Detection and Error Recovery a. Geographic Section Error The Serial Command Link that connects the Geographic Sections to the Level 1 and Level 2 Trigger Frameworks carries an error signal from the Geographic Sections is received by the Level 1 Trigger Framework. The 128 Geographic Section Error Signals are received and monitored on a dedicated module of the Level 1 Trigger Framework. Whenever one of the Geographic Sections is reporting an error, and that Geographic Section is programmed to be readout by at least one of the Specific Triggers, then the Trigger Control Computer is notified with a hardware interrupt. In response to a Geographic Section Error the Trigger Control Computer is expected to: i) stop Trigger operation ii) record the origin of the error signal iii) send a reset request to ALL the Geographic Sections (using the Serial Command Link) iv) verify that all Geographic Sections advertize they are ready again v) resume data taking Only one error signal is defined on the Serial Command Link from each Geographic Section. This error signal is used to flag multiple types of errors. The Level 1 Trigger Framework cannot find out the type of error is being signaled, and only keeps track of which Geographic Section reported the error, with what rate, and for how many times since the Level 1 Trigger System was most recently initialized has each Geographic Section reported errors. The Geographic Sections themselves must record detailed information about the errors. This information is accessed via a separate path, and not my TCC. The details of error detection and reporting in the Geographic Sections is beyond the scope of this document, and the following description is merely an introduction. All messages from the Trigger Frameworks to the Geographic sections that either inform the Geographic Sections of an L1 Accept or that instruct the Geographic Sections to drop an event, or to transfer an event to Level 3, always carry a unique event identification number for the event that is being referred to in the message. This event identification number is the L1 Trigger Number as used by the Geographic Sections and is made from the combination of the 16 bit Turn Number and the 8 bit crossing ID. Given the L1 Trigger Number and certain rules the Geographic Sections can looks for two types of errors. If a Geographic Section receives an L1 Accept message with an L1 Trigger Number (i.e. Turn Number and Crossing ID) that does not match the data at the end of its L1 History FIFO Buffer then the Geographic Section signals an error. The Geographic Section must signal an error because it does not agree with the L1 Framework about which history sample should be captured by this L1 Accept message. The other type of error that is detected in the Geographic Sections on the bases of L1 Trigger Number involves data in the Geographic Sections L2 Buffer; the buffer that holds events awaiting their Level 2 Trigger decisions. If a Geographic Section receives an L2 Accept or L2 Reject message with an L1 Trigger Number that does not match the the data for the event at the end of its L2 Buffer then the Geographic Section must signal an error. The error condition exists because the Framework and the Geographic Section do not agree about which event was currently receiving its L2 decision. b. Level 3 request for Initialization of Geographic Section If the Level 3 system can detect a class of errors that would otherwise go unnoticed by the Geographic Sections and the Level 1 Trigger Framework alone, (e.g. data cable sequencer errors) AND the recovery process required for this class of errors includes Initializing the Geographic Sections then a mechanism needs to be provided that will allow the L3 System to ask the Level 1 Trigger Framework to request an Initialization of the Geographic Sections. c. And-Or Input FIFO error As presented in 3.a. the And-Or Terms are supplied with an accompanying strobe signal, and are received by a FIFO register. Every 132 ns he Level 1 Trigger Framework reads the output of the FIFO and retrieves the state of the And-Or Term for the beam crossing currently analyzed. The And-Or Term State for this particular crossing has arrived a certain number of 132 nsec periods after the actual beam crossing but must have arrived before it is used by the Level 1 Framework (cf. http://www.pa.msu.edu:80/hep/d0/ftp/l1/framework/ andor_terms/receiving_l1_framework_input_terms.txt for specification details). The FIFO should never be found empty, or an error is flagged. Likewise, the condition where the FIFO is found NOT empty right after the Level 1 Trigger Framework processes the last beam crossing before an accelerator turn gap will generate an error. The Level 1 Trigger Framework detects these errors, and keeps track of the rate and total number of occurrences of the problems for each And-Or Term. The Level 1 Trigger Framework does not, and cannot, fix or flag events affected by an And-Or synchronization error, as the problem had most likely started earlier than when it was detected. The L1 Trigger Framework will still inhibit the firing of ALL Specific Triggers and for ALL beam crossings AFTER the discovery of an And-Or Term Input FIFO error until synchronization with ALL And-Or Term Sources is regained (which might take a number of turns in the accelerator). These errors are self correcting, as the And-Or Input FIFO can be reset at each accelerator turn. An error detected during one Accelerator Turn does not propagate into the next Super-Bunch, and no instantaneous intervention from the shift operators, or the Trigger Control Computer is necessary besides counting and logging the errors. d. Connection to DZero Alarm System The Trigger Control Computer reports errors to the centralized DZero Alarm System. The details of what errors and conditions are reported haven't been worked out yet. TCC will also relay Alarms from the Level 2 Alpha Crates under its supervision. 11. Luminosity and Exposure Groups a. Scalers for Luminosity Measurement It is our intent in the design of the L1 Trigger Framework to provide all the scalers necessary to measure the luminosity online. This includes the instantaneous and integrated delivered beam luminosity and the luminosity each particular Specific Trigger has been exposed to. A brute force approach requires a set of 159 scalers (one for each bunch in the machine) for each of the 128 specific trigger being monitored, but the resulting 20,000 scalers would come with a high price for hardware implementation and software control. If we can limit the number of different configurations of the specific triggers in the way they select which beam crossings they are exposed to, we can then limit the number of sets of sets of 159 scalers needed. Furthermore, we can separate the correlated aspects of the way the specific triggers select which beam crossings they are exposed to from the de-correlated aspects. The correlation of non-correlation being related to the luminosity in a particular bunch and the bunch luminosity profile along the accelerator turn in general. The Level 1 Framework fully monitors the correlated aspects with one full set of 159 per-bunch scalers for each independent combination. That is what the Exposure Groups represent. We also monitor each Specific Trigger for its de-correlated correction, which only requires one additional luminosity scaler per Specific Trigger. cf. http://www.pa.msu.edu:80/hep/d0/ftp/l1/framework/exposure_groups/ measuring_luminosity_online.txt for more details on correlated and de-correlated sources of Specific Trigger Disable. b. Exposure Groups The concept of Exposure Group is introduced to allow accurate monitoring of the instantaneous and integrated luminosity of each Specific Trigger. The resources covered by the Exposure Groups must cover all aspects of Beam Crossing Selection that are (or may be) correlated with the Bunch Luminosity profile. There are 8 independent Exposure Groups. Each Exposure Group specifies - a set of And-Or Input Terms e.g. for beam quality information, multiple interactions, detector recovery,... - a set of Geographic Sections which will receive a Start Digitize and subsequently whose Front-End Busy signal must be obeyed - a set of Specific Triggers Global Disable Signals c. Specific Trigger Luminosity Exposure The programming of a Specific Trigger specifies which Exposure Group it belongs to. Additional firing restrictions may be programmed into the Specific Triggers, as long as they are fully de-correlated from the Bunch Luminosity profile. This includes Specific Trigger Prescaling, any source of individual per-Specific Trigger or Global Disable, enabling/disabling from COOR. The Level 1 Framework will keep track of these de-correlated contributions to the Specific Trigger Exposure with one additional scaler per Specific Trigger dedicated to online luminosity measurement. cf. http://www.pa.msu.edu:80/hep/d0/ftp/l1/framework/exposure_groups/ measuring_luminosity_online.txt for details on the algebra involved. 12. Trigger Control Computer The Level 1 Trigger Framework is controlled by the Trigger Control Computer (TCC). The TCC also controls the Level 2 Trigger Framework, the Level 1 Calorimeter Trigger. The TCC also serves the Level 2 Global Processor Crate, the Level 2 Calorimeter Trigger Pre-Processor Crate, the Level 2 Muon Trigger Pre-Processor Crates, and all other Alpha based Level 2 Pre Processor Crates (cf. http://www.pa.msu.edu/hep/d0/l2/ for the full list of Level 2 Pre Processors). a. TCC access to the Trigger hardware The Trigger Control Computer is an Intel based PC running the Windows NT operating system. TCC communicates with the VME based Trigger Hardware using a Bit3 Bus adapter. cf. http://www.pa.msu.edu:80/hep/d0/ftp/tcc/vme_access /vme_communication_crate.txt for details on this communication path. b. link to COOR TCC, or more precisely the Trigger Control Software, is the interface used by COOR, the global coordinating program for the DZero experiment. COOR reads the user's requests, allocates the resources needed, and configures all components of the Acquisition system required to fill the request. TCC receives high level programming requests from COOR and translates the commands to perform the low level register programming actions to carry out the request. The resources available to COOR (and ultimately the user) are: - Specific Trigger (128) resources available for each Specific Trigger: - And-or Terms (256) - List of terms used for And-Or Beam Conditions and the polarity required for each term in the list - Global Enabling/Disabling of each Specific Trigger - Enable Specific Trigger Prescaling and set a prescale Ratio from - Auto-disabling of Specific Trigger and related requests to reenable Auto-disabled Specific Trigger - Which Exposure Group the Specific Trigger belongs to - Level 1 Trigger Exposure Group (8) for which the exposure to the delivered beam luminosity is monitored on a per-Bunch basis - And-or Terms (256) List of terms used for And-Or Physics requirements and the polarity required for each term in the list - Geographic Sections (128) List of Geographic Sections to Digitize and thus whose Geographic Section Busy signals must be obeyed - Level 1 Trigger Accept Qualifier (16) For each Level 1 Trigger Accept Qualifier: - the list of Specific Triggers that will set the Qualifier. The Qualifier is set as soon as any of the Specific Triggers in this list has fired. - Other global commands - Load Hardware FPGA Configurations - Initialize Level 1 Trigger Framework - Initialize Front-Ends via SCL's (Serial Command Links) - Run Pause/Resume - Begin/End Run Report File - List of Geographic Sections currently online, and thus for which TCC should monitor (and react) to SCL L1/L2 Error from. c. Monitoring data server TCC is also a server of monitoring data (see 8.c.) to host based programs (TRGMON, Global Monitoring, Luminosity Server) and provides information about all the systems it manages, including L1 and L2 Trigger Frameworks, and L1 Calorimeter Trigger. d. Alarms TCC can connect to the centralized Dzero Alarm system. The details of what errors and conditions are reported haven't been worked out yet. TCC will also relay Alarms detected in the Level 2 Alpha Crates under its supervision. e. Diagnostics Besides the nominal set of high level commands needed by COOR to configure the system for it normal use, TCC also provides additional commands for the trigger hardware specialist. These commands, or set of commands can also be made accessible to the operator when the Level 1 Trigger hardware setup must be modified for non-standard use. These additional commands include other COOR-like high level commands, detailed lower level commands, very specific register level commands, along with access to the tests and diagnostics programs to exercise in situ the components of the system. 13. What is missing from this document a. Lack of information Some descriptions are missing from this document for services that are currently foreseen but whose definition hasn't yet been worked out . - alarm messages sent by TCC to the DZero Alarm Server - command message protocol between COOR and TCC cf. current draft in http://www.pa.msu.edu:80/hep/d0/ftp/tcc/coor/coor_resources.txt - Foreign Scalers (cf. Run I) in the L1 Trigger Framework hardware and readout mechanism. Some Foreign Scalers will also provide per-bunch counting. b. Explicitly excluded Some items have been explicitly excluded from this document as they will NOT be part of and NOT supported by the Level 1 Trigger Framework during Run II. - NO "garbage collection". The Level 1 Trigger Framework data block will NOT be used to read out and transport miscellaneous information unrelated to the Level 1 Trigger Framework as was done during Run I (e.g. Pulser programming readout). The Level 1 Readout will use a VME Readout Buffer Crate (VRB) and will not be able to import outside information as could be done more easily in Run I with a VBD and 68k VME CPU Readout system. 14. Known Limitations The following items might have already been presented in the body of the document, but are repeated and regrouped here. a. No OR-ing of And-Or Terms in Specific Trigger What has sometimes be perceived as a limitation during Run I, but is an underlying principle of the Level 1 Trigger design, is that each Specific Trigger is only allowed a single set of And-Or requirements. The "OR" found in the word And-Or Network refers to the Global L1 Trigger decision being the "OR" of the Specific Trigger decisions. Allowing several distinct sets of And-Or requirements in a given Level 1 Specific Trigger would cause accounting problems, and filtering problems later on, in the Level 2 and Level 3 Triggers that would need to decode and find which sub-condition(s) were met. When OR-ing of And-Or Term requirements is necessary, the user should instead define and allocate multiple Specific Triggers with one requirement per Specific Trigger. This constitutes part of the motives for increasing the number of Specific Triggers from 32 during Run I to 128 for Run II. b. Less scalers in data block than for Run I An effort was made to minimize the quantity of information read out in the Level 1 Trigger Framework Data Block. Large amount of data lowers the maximum event readout rate, increases the event size, and increases dead time while the Level 1 Trigger Framework captures the current data and before it can be ready for the next event. Most of the scalers that were readout with each event during Run I are not available in the data stream during Run II. The experiment should rely instead on the services of the Begin/End Run files and the logging of vital information should into databases at regular intervals during each run. c. Minimum previous/next information in data block Some information about the previous, and also the next Beam Crossing is useful and is read out. While during Run I all the Level 1 Trigger Framework data was systematically readout twice, once for the current Beam Crossing and once for the preceding Beam Crossing, only the relevant information is being read out during Run II and it is read out for the previous and next crossings. Namely, the quantities that are still read out for the previous and next crossings are - For each Specific Trigger its: - Exposed State - Physics And-Or Term Fired Signal - Beam condition And-Or Fired Signal - the State of all And-Or Input Terms (in fact the state for three 132 ns ticks around trigger crossing)