Note: we also need to write the 2 pages + 2 drawings about Run II Trigger+DAQ Note: the version released to DZero will have to be Tex Note: things to check in the draft are flagged with ??? -> use search D0 Run II Level 1 Trigger Framework -------- Michigan State University Draft 5-DEC-1995 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 (??? I had to make up a name) 3. Physics input to the Level 1 Trigger Framework a. And-or Input Terms b. Physics vs Beam Condition And-or combination c. Programmable Bunch Select And-Or Terms d. No Direct-In Test Triggers e. What happens during the Super-Bunch gaps 4. Interface with the Data Acquisition System 5. Latency and Rates 6. Event Flow Control a. Enable/disable: b. Front-End Busy c. Level 3 Disable d. Prescaler: e. Autodisable: 7. Event Identification a. Beam Crossing Number b. Level 1 Trigger Accept Number c. Absolute time / ACNET time <---- Dan, can you write this ??? 8. Trigger Information Output a. High speed outputs b. Level 1 Trigger Framework Data Block c. Monitoring data serving 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 Front-Ends c. And-or Input FIFO error d. Connection to DZero Alarm System 11. Luminosity <------------------- don't know what to say yet ??? 12. Trigger Control Computer a. link to COOR b. Monitoring data server c. Alarms d. 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 Appendix A. And-or Input Terms Cables Appendix B. Serial Command Link <---------- Existing? but Not yet Included ??? Appendix C. Specific Trigger Fired Cables Appendix D. L1 Trigger Framework Data Block <---- Not done yet ??? 1. General This document describes the Level 1 Trigger Framework for Run II of the Fermilab Collider program. The Level 1 Trigger Framework for Run I was defined in D0 Notes #328 and #705. The Level 1 Calorimeter Trigger for Run I was described in D0 Note #706. The Level 1 Trigger Framework implements one component of the Level 1 Trigger System for D-Zero. Furthermore the Level 1 Trigger System is only one part of the overall Trigger and Acquisition system for D-Zero. For a Global view of the Trigger and Acquisition system of D-Zero see companion D0 Note # ??? (*** This is the new "2 pages + 2 drawings" note that we need to write ***) The Level 1 Trigger System is a hardware trigger system filtering the 7.59 MHz rate of Beam Crossing delivered (i.e. 132 ns apart) with minimal Dead Time (less than 5% ??? desired running conditions). The Level 1 Trigger System consists of the Level 1 Trigger Framework and the Level 1 Trigger Subsystems (cf. Figure 1). Each Level 1 Trigger Subsystem processes detector-specific information and produces, for every Beam Crossing, an indication of the activity seen by its associated Detector component. These indications are transmitted to the Level 1 Trigger Framework, which determines whether the Beam Crossing is to be rejected, or the event 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 Trigger decision for Run II is not made between Beam Crossings; it is however generated with a fixed latency after a given Beam Crossing. An important basic property of the beam delivered for Run II is that the Bunches of particles in the accelerator are not equally spaced: while most Bunches are 132 ns apart, there are 3 gaps (about 2 microseconds each) with no crossings, and the resulting 3 groups of 132 ns equally spaced Beam Crossings are called Super-Bunches. The Level 1 Trigger Framework guarantees that never more than one positive Level 1 Trigger Decision (called Level 1 Trigger Accept) is issued during one Super-Bunch. The Level 1 Trigger Subsystems perform, in hardware, relatively simple fixed algorithms with programmable parameters. The Level 1 Trigger Framework needs to pick one event out of every 400-500 (???) Beam Crossings, or one out of every 10-20 (???) Super-Bunches. 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 DZero experiment, and performs the low level register programming actions to carry out the request. 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 extended 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. Special FPGA programming on this common platform universal card produce the different functions needed throughout the system. Only a few different versions of this universal card are needed and they differ only in the routing of internal traces. The main differences with run I 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 64 (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 the And-Or Input Terms. There is a maximum of 256 And-or Input Terms available. One And-Or Input Term is a input binary signal that is captured for every Beam Crossing; it is a one-bit state which, for a given crossing, can be found 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) can use the And-Or Input Term mechanism to become part of the Trigger decisions. The primary usage 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 are needed for sorting Beam Crossings and forming a 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). b. Specific Trigger For every Beam Crossing 64 separate sets of And-Or Term combinations are performed. The result is used to produce 64 separate Specific Trigger Decisions. The global Level 1 Trigger Decision is the logical .OR. of the 64 Specific Trigger Decisions; the global Level 1 Trigger Decision will be positive (called Level 1 Trigger Accept) as soon as at least one of the 64 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 are met. Before a Specific Trigger can fire, the rest of the Acquisition system must be able to accept an event produced by this Specific Trigger. Each of the 64 Specific Triggers can be independently enabled or disabled by COOR at any given time. A Specific Trigger can also be prescaled. c. Geographic Section Any part of the D-zero Acquisition system that needs to capture data for events selected by the Level 1 Trigger, and needs to be told whether and when to send this data to the Level 2 and/or Level 3 Trigger system is connected to the Level 1 Trigger Framework by a Serial Command Link. The Acquisition subsystem or the group of subsystems sharing one Serial Command Link is called a Geographic Section. During Run II Dzero will allocate one Geographic Section for each VBD card (VBD = VME Buffer Driver; card collecting and sending data over the Data Cables to Level 3). The Serial Command Link (cf Appendix B) is a two-way communication link where the Level 1 Framework tells the Geographic Section which Beam Crossings to capture (Start Digitize Signal), and where the Geographic Section tells the Level 1 Trigger Framework when it is not in a state to accept an event (Front-End Busy Signal). The Level 1 Trigger Framework can support up to 128 Geographic Sections. Typical Geographic Sections are detector Front-Ends, but other subsystems contribute data to the event. For example, the level 1 Trigger Framework uses a standard Geographic Section to control its data readout. Another special case which uses a standard Geographic Section is the Level 2 Processor Farmlet that needs to send the result of the Level 2 processing to the Level 3 Trigger 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 may benefit from a partition of the Data Acquisition system. A given Specific Trigger may require that only a specified fraction of the Geographic Sections be digitized while another Specific Trigger is collecting data from a different fraction of the Geographic Sections. d. Readout from Level 1 Trigger Framework The Level 1 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 outlined in Appendix D. 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. The Level 1 Trigger Framework uses the same SAR cards (SAR stands for ???) as used by the Central Detectors for readout in Run II. Less information is being readout for Run II as compared to Run I. In particular fewer Scalers are being readout and not all data is systematically readout for the previous crossing (cf. section 8). 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 operation. The first class is for monitoring proper activities and data flow by the DZero operators and experts using host programs like TRGMON. The data obtained during this type of monitoring is only of instantaneous, temporary interest, but may occasionally be captured in logbooks. Trigger rates, dead time, etc are used to verify proper operation of the system and, at times, this type of information is used to investigate and locate problems when the system breaks down. In contrast, the second class of monitoring is for long term usage and becomes 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 Trigger Live time are examples of this class of information, which must be recorded at regular interval during every run since the luminosity in the machine is changing (dropping rapidly) with time. f. Specific Trigger Groupings (??? I had to make up a name) A new service is started during run II to improve monitoring and provide new control signals if needed. The Specific Trigger Grouping service lets the users define up to 64 independent groups of Specific Triggers. For each such group a programmable arbitrary list of Specific Triggers is specified: the Specific Trigger Group signal is asserted when at least one Specific Trigger in the list has fired. The signal is set at the same time as the the Start Digitize Command sent to the Geographic Section This service can be used as a source of "Pseudo-Geographic Section Start Digitize Signal" if some activity needs to be synchronized with the firing of some of the Specific Triggers. Scalers are attached to the Specific Trigger Groupings to provide instantaneous and integrated monitoring of the occurences. This monitoring can be used to follow the combined rate of a group of Specific Triggers by properly accounting for their overlap. 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 systems that might have very different latencies. The different systems also provide their own clock signal so that all systems are NOT required to bring their timing and cable delays in phase with a 132 ns clock provided at the Level 1 Trigger Framework. The And-Or Input Terms are received in groups of 16, with each group carrying a Strobe signal to tell the Level 1 Framework when to sample the 16 And-Or Term signals. The And-Or Term and And-Or Strobe signals must be presented to the Level 1 Trigger Framework as differential ECL signals (cf. Appendix A). The FIFO implemented in the And-Or Term Receiver Module has a maximum depth of 25 (???), corresponding to the agreed maximum 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 FIFOs for a given Beam Crossing 3.36 microseconds after the Beam Crossing time to start forming the Level 1 Trigger Decision. 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 vs Beam Condition And-or combination For each Specific Trigger not one, but two programmable combinations of And-Or Input Terms are performed separately and accounted for separately. These two combinations participate in different ways to the Specific Trigger Decision. The first programmable combination produces the "Physics" And-Or Decision and is scaled to keep track of how many times the Specific Trigger physics conditions were met and with what current rate. The second programmable combination produces the "Beam Condition" Decision which becomes part of the Specific Trigger enable signal which is scaled separately to account for exposure to luminosity. The two And-Or requirements, Physics and Beam Condition, of each Specific Trigger are independently programmable. For each And-Or Term a Specific Trigger can be programmed to either ignore the state of this particular And-Or Term, or include it in its requirement. When an And-Or Term is included, the And-Or requirement specifies either that the And-Or Term must be found asserted or that it must be negated to satisfy the And-Or requirement. c. Programmable Bunch Select And-Or Terms The Level 1 Trigger Framework provides a mechanism to select a particular Bunch Crossing out of the 96 Bunches in the accelerator. Instead of allocating 96 out of the 256 And-or Terms to implement this functionality, 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 had 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 was 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 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 As mentioned above the Beam provided by the Accelerator during Run II presents 3 Super-Bunches and 3 corresponding gaps with no Beam Crossings. The Level 1 Trigger Framework requires the And-Or Term Strobe NOT to be asserted for empty Beam Crossings. To direct the systems providing And-Or Input Terms the Level 1 Trigger Framework sends precise instructions to the Geographic Sections using the Serial Command Link. The Level 1 Trigger Framework specifies, for each Beam Crossing, whether And-Or Terms will be expected at the Level 1 Trigger Framework. This information is available for every 132 ns interval and at the time of the Beam Crossing (??? more precisions?). 4. Interface with the Data Acquisition System The Level 1 Trigger Framework is connected to the rest of the Acquisition system by specialized communication links transporting bi-directional information. The Acquisition system is divided into 128 Geographic Sections, each associated with one Serial Command Link. A Serial Command Link is a fiber optic synchronous serial connection with a protocol defining the exchange of bi-directional messages. Each Serial Command Link associated to a Geographic Section is actually shared with the Level 2 Trigger Framework for sending messages; the Level 2 messages are multiplexed on the link with the highest priority given to the Level 1 messages. The interface from the Level 1 (and Level 2) Trigger Framework for the Geographic Sections to access the actual Serial Command Links as seen by the Level 1 and the Level 2 Frameworks are the SLIM Modules. The main types of information transported over the Serial Command are summarized below. Information sent by the Level 1 Trigger Framework: - Start Digitize with Trigger Number and Bunch Crossing identification (Simple but somewhat misleading name kept for historical reasons as the full meaning is "Capture event and send information to the Level 2", digitization is not always performed at this stage). - Initialize front-Ends (requested by COOR, or after a protocol error has been detected by the Front-End) - Active Beam Crossing Status (The Level 1 Trigger Framework specifies which 132 ticks have Beam Crossings and which ticks correspond to beamless gaps) Information received by the Level 1 Trigger Framework: - Front-End Busy (This is also an imprecise name, which was also kept for historical reasons. This signal signifies that the Front-End is not currently in a state where it could capture an event; the Front-End could in fact well be idle, but have simpy run out of buffers to store another event) - Error (Several rules can be checked at the Front-Ends and buffer synchronization errors can be detected and signaled by the Front-Ends. cf. 10.a) The availability of the information at the receiving ends of the Serial Command Links is always fixed at 132 ns, even it the Beam Crossing rate is ever switched from 132 ns to 396 ns. The definition of the Serial Command Link can be found in appendix B. 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 the And-Or Term Input FIFOs for a given Beam Crossing after tick 25 (3.30 microseconds after T0) to start forming the Level 1 Trigger Decision. All Inputs must have reached the Level 1 Trigger Framework by that time (cf Appendix A). The Level 1 Trigger Framework will have formed its decision by tick 27, and the decision will reach the Geographic Sections at tick 30 (i.e. 3.95 microseconds after T0). 6. Event Flow Control a. Enable/disable: Each of the 64 Specific Triggers can be independently enabled or disabled by COOR at any given time. b. Front-End 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 is thus able to request that all Specific Triggers requiring this Geographic Section data be disabled for the current crossing because the associated Front-End is not in a state where it could capture another event. In other words the Specific Trigger is Exposed only for the Beam Crossings where it is allowed to fire. Different Geographic Section can advertize themselves as being front-end busy at different times, and for different reasons. A common reason where a Front-End may need to stop event flow 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 allow and process another Level 1 Accept. Another reason to assert the Front-End Busy signal may be to protect the Front-End information during a window vulnerable to data capture or data management (e.g. right after a Level 1 Trigger Accept). Note that the Level 1 Trigger Framework guarantees a minimum time separation between successive Level 1 Trigger Accepts of ??? microseconds. During this minimum window the Geographic Sections do not need to signal themselves as Front-End Busy and no new Level 1 request will be presented to them. But if a Geographic Section is not done by the end of the window it will need to have asserted the Front-End Busy Signal to make sure it does not receive another Start Digitize request. The Front-Ends communicate their availability to the Trigger Framework using the Front-End Busy signal of the Geographic Section via the Serial Command link (cf. paragraph 4 above). c. Level 3 Disable The Level 3 system may also 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 the events will backup in the front-end's transfer buffers, and the Geographic Sections already 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. A Specific Trigger is prescaled when it is programmed with a particular Prescale Ratio "n" meaning that it will only be exposed to 1 out of every n Beam Crossings. More precisely, the Specific Trigger is exposed for one whole turn of all the particle Bunches in the accelerator, then disabled for the next (n-1) turns, then enabled again for another whole turn, and so forth. (??? this is still being argued ) 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 after each time it has fired and before it can fire again. 7. Event Identification a. Beam Crossing Number Each event will be stamped with a Beam Crossing Number to uniquely identify the exact Beam Crossing for 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 location 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 Spot ID (??? I had to make up a name) which specifies the position of the Beam Crossing within the turn. This Spot ID is the time delay in units of 132 ns from the Bunch P1 (e.g. P1 has Spot ID 0, P2 is 1,...). Note that the Spot ID is sent to the Front-Ends over the Serial Command Link to identify the Beam Crossing within the Super-Bunch that caused the Level 1 Trigger Accept. 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 (sometimes referred to simply as the Level 1 Trigger Number). This number is incremented after every Level 1 Trigger Accept; note that the lower 16 bits of this number are used in the Serial Command Link to identify the event. c. Absolute time / ACNET time <---- Dan, can you write this ??? 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 and Level 3 Trigger Frameworks via private cables (cf. Appendix C). 64 parallel signals are sent along with a Strobe signal that correspond to the Level 1 Trigger Accept signal and tells the receiving system when to latch the information on the cable. The 64 Specific Trigger Grouping Signals form another type of high speed, specialized information output. The Specific Trigger Grouping service lets the users define up to 64 independent groups of Specific Triggers. For each such group a programmable arbitrary list of Specific Triggers is specified: the Specific Trigger Group signal is asserted when at least one Specific Trigger in the list has fired. The signal is set at the same time as the the Start Digitize Command sent to the Geographic Section, at tick 27. Other high speed communications are being studied. In particular, the possibility of the Level 1 Trigger Framework providing the Level 2 Processing Farmlet directly with the mask of which Level 2 filters need to be evaluated as required by the mask of Level 1 Specific Trigger Fired. (??? If we like the idea, shouldn't we start pushing it...) b. Level 1 Trigger Framework Data Block The Level 1 Framework is a standard Geographic Section which 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. As currently planned this data is NOT sent to the Level 2 Trigger (???). The Level 1 Trigger Framework Data Block is outlined in Appendix D. The Level 1 Trigger Framework Data Block is systematically present with every event recorded at DZero. The information captured can be classified to fall 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 being readout is captured for the Beam Crossing that caused the event, with all parts being 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 as compared to Run I: fewer Scalers are being readout and not all data is systematically readout for the previous crossing. Another major difference with comparison to Run I is that the Level 1 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 at different times, and for several purposes. The Level 3 Trigger may need to access this information to provide filtering (for example read the state of some And-Or Input Terms for the current or previous crossing), and this information is accessible offline during physics analysis. The Level 1 Trigger Simulator needs to access this data and read the inputs to the Framework to be able to recreate the Trigger Decision for verification, or, under 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 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 is able, at any time, to request a copy of the Level 1 Trigger Framework Data Block for the next event and then access this copy. When the offline user wants to access information recorded in the Level 1 Trigger Framework Data Block he should look for the appropriate L1EXTRACT_* access routine, or inquire about creating new routines to fill a particular need. c. Monitoring data serving The Trigger Control Computer (TCC) gathers monitoring data and can serve monitoring information to remote programs. The data is collected at regular interval (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. 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, and 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, with shorter and more frequent stores. During Run I, each run was taken at a (somewhat) constant luminosity, and with a constant set of Specifid 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. Another luminosity service program (called PER_BUNCH_LUM during run I; by Dan Owen) reads Per Bunch Scaler information from TCC to compute the instant luminosity delivered at DZero, and writes a number of related quantities to ACNET. 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 File. 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 are still always available to run analysis programs. In particular the Luminosity Server program uses these file 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 a wide 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, and programs that can exercise 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. 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 for. It is also an important tool to catch problems as early as possible, and prevent large amount of data to be 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 also an error signal from the Front-Ends that is received by the Level 1 Trigger Framework. The 64 Geographic Section Error Signals are received and monitored on a dedicated module of the Level 1 Trigger Framework. Whenever one of the Geographic Section is reporting an error, 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, and this error signal is used to flag multiple types of errors. The Level 1 Trigger Framework cannot find out the type of error 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 initialized. The Front-Ends must record detailed information about the errors, and is interrogated via a separate route. The details of error detection and reporting in the Front-Ends is beyond the scope of this document, and the following description is merely an introduction. All requests sent to the Front-Ends to capture, drop, or transfer an event always carry an event identification number (the low 16 bits of Level 1 Trigger Number), while the rules of the data acquisitions are such that the event being dropped or transfered must always be, by definition, the last event present in the buffer pipelines. The Front-End can thus compare the Trigger Number in the request received to the Trigger Number found in the last buffer location. An error is generated when a mismatch is detected, corresponding to a buffer management error. There are two sets of buffers: the buffers for events accepted by Level 1 and awaiting Level 2 Processing, and the buffers for events accepted by Level 2 and awaiting transfer to Level 3. Both sets of buffers can detect mismanagement errors in the manner that was just presented. b. Level 3 request for initialization of Front-Ends This topic is not fully understood at the moment. If the Level 3 system can detect a class of errors that would otherwise go unnoticed by the front-ends and the Level 1 Trigger Framework (e.g. data cable sequencer errors) AND the needed recovery actions require a reset of the Front-Ends, a mechanism needs to be provided for the Level 3 management system (e.g. Level 3 Supervisor) to notify the Level 1 Trigger Control Computer and request a Front-End Reset. 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 memory. The Level 1 Trigger Framework reads the FIFO after a fixed time delay from the Beam Crossing. a FIFO found empty signifies a missing And-Or Term for the Beam Crossing currently evaluated and/or for preceding Beam Crossings. Likewise, the condition where the FIFO is NOT found empty at the end of a Super-Bunch corresponds to extra strobe signals received and is an And-Or Term error for all or some of the Beam Crossings in the Super-Bunch. The Level 1 Trigger Framework detects these errors, and keeps track of the rate and total occurance of the problems for each And-Or Term. The Level 1 Trigger Framework does not and cannot fix or flag the events affected by the error, as the problem had most likely started earlier in the Super-Bunch. (??? actually ... since there is only one Accept per Super-Bunch, we CAN prevent the damage, by simply "preventing" the event where the error is detected from coming out, and vetoing all events till the end of the Super-Bunch. Probably we should only take such drastics actions for And-Or Terms actually used ???) These errors are self correcting, as the And-or Input FIFO is reset before every Super-Bunch. An error during one Super-Bunch does not propagate to the next Super-Bunch, and no instantaneous intervention from the shift operators, or the Trigger Control Computer is necessary. 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. 11. Luminosity what scalers are available Live time fraction now measured per spec trigger prescaler effect well understood/accountable 12. Trigger Control Computer The Level 1 Trigger Framework is controlled by the Trigger Control Computer (TCC). The TCC is shared between the Level 1 Trigger Framework, the Level 2 Trigger Framework, and the Level 1 Calorimeter Trigger. a. 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 (64) 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 - 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 obey Front-End Busy signals - Global Enabling/Disabling of Specific Trigger - Enable Specific Trigger Prescaling and set a prescale Ratio (from 1 to ???) - require Auto-disabling of Specific Trigger and related requests to reenable Auto-disabled Specific Trigger ??? - List of which Specific Trigger And-Or Beam Conditions should be monitored on per Bunch basis (??? that's if we end up limiting the number of And-Or Beam Conditions and connect 100 scalers to each combination) - Specific Trigger Groupings (64) For each Specific Trigger Grouping: - the List of Specific Triggers in the group - Other global commands - Initialization (??? is there a reload separate from Initialize) - Pause/Resume - Begin/End Run File ??? - Mapping of Level 1 Specific Trigger to Level 2 Filters (??? If we like the idea, shouldn't we start pushing it) - Programming of Bunch Select And-Or Terms (8) b. 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 the systems it manages: L1 and L2 Trigger Frameworks, and L1 Calorimeter Trigger. c. 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. d. Diagnostics Besides the nominal set of high level commands needed by COOR to configure the system for designed use, TCC also provides additional commands to 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 more high level commands, lower level commands, register level commands, along with tests and diagnostics programs to exercise in situ components of the system, or variable fractions of the system hardware. 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 - Foreign Scalers (cf. Run I) in the L1 Framework hardware and readout mechanism b. Explicitely 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). 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 Term refers to the ability to ignore some of the And-Or Terms whose state are irrelevant to the Level 1 Trigger Decision. Allowing several distinct sets of And-Or requirements in Level 1 Trigger programming 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 64 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 Level1 Trigger Data Block. Large amount of data lowers the maximum event readout rate, increases the event size, and increases dead time while the Level 1 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 onto 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 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 read out for the previous and next crossings are the - State of all And-Or Input Terms - For each Specific Trigger its: - Exposed State - Physics And-Or Term Fired Signal - Beam condition And-Or Fired Signal Appendix A And-or Input Term Cables The And-Or Input Terms are received in groups of 16, with each group carrying a Strobe signal telling the Level 1 Framework when the And-Or term Signals are stable and should be sampled. The And-Or Term and And-Or Strobe signals must be presented to the Level 1 Trigger Framework as differential ECL pairs. All signals are Positive True logic. The And-Or Term signals are captured at the falling edge of the Strobe Signal. The Strobe Signal should be asserted for between 40 nsec and 60 nsec (???). The Strobe Signal should be negated for 50 nsec minimum before being asserted again (???). The And-Or Term lines should be stable for 50 nsec (???) minimum before the falling edge of the Strobe Signal and should hold for 50 nsec (???) minimum after the falling edge of the Strobe Signal. All signals are differential ECL levels carried over 34 conductor twisted-flat cables with the non-inverted signal connected to the odd-numbered pins, and corresponding inverted signal connected to the following even-numbered pin. The first pair of conductors (pins 1 & 2) of a given cable carry the first And-or Term of the group while the last pair of conductors (pins 33 & 34) carry the Strobe Signal (???). At the Receiving End (i.e. the Level 1 Trigger Framework) the cable is terminated with a 110 Ohm resistor across each differential pair of lines. The Sending End must provide the pull down resistors to Vtt. CABLE FROM A LEVEL 1 TRIGGER SUBSYSTEM, OR GENERIC LEVEL 1 INFORMATION PROVIDER ----------------------------------------- PIN # CABLE COLOR SIGNAL POLARITY ------- ------------- -------- ---------- 1 BROWN AND-OR TERM # 0(RELATIVE) NON-INVERTED 2 TAN AND-OR TERM # 0(RELATIVE) INVERTED 3 RED AND-OR TERM # 1 NON-INVERTED 4 TAN AND-OR TERM # 1 INVERTED 5 ORANGE AND-OR TERM # 2 NON-INVERTED 6 TAN AND-OR TERM # 2 INVERTED 7 YELLOW AND-OR TERM # 3 NON-INVERTED 8 TAN AND-OR TERM # 3 INVERTED 9 GREEN AND-OR TERM # 4 NON-INVERTED 10 TAN AND-OR TERM # 4 INVERTED 11 BLUE AND-OR TERM # 5 NON-INVERTED 12 TAN AND-OR TERM # 5 INVERTED 13 VIOLET AND-OR TERM # 6 NON-INVERTED 14 TAN AND-OR TERM # 6 INVERTED 15 GREY AND-OR TERM # 7 NON-INVERTED 16 TAN AND-OR TERM # 7 INVERTED 17 WHITE AND-OR TERM # 8 NON-INVERTED 18 TAN AND-OR TERM # 8 INVERTED 19 BLACK AND-OR TERM # 9 NON-INVERTED 20 TAN AND-OR TERM # 9 INVERTED 21 BROWN AND-OR TERM #10 NON-INVERTED 22 TAN AND-OR TERM #10 INVERTED 23 RED AND-OR TERM #11 NON-INVERTED 24 TAN AND-OR TERM #11 INVERTED 25 ORANGE AND-OR TERM #12 NON-INVERTED 26 TAN AND-OR TERM #12 INVERTED 27 YELLOW AND-OR TERM #13 NON-INVERTED 28 TAN AND-OR TERM #13 INVERTED 29 GREEN AND-OR TERM #14 NON-INVERTED 30 TAN AND-OR TERM #14 INVERTED 31 BLUE AND-OR TERM #15 NON-INVERTED 32 TAN AND-OR TERM #15 INVERTED 33 VIOLET AND-OR TERM STROBE NON-INVERTED 34 TAN AND-OR TERM STROBE INVERTED Appendix B Serial Command Link Appendix C Specific Trigger Fired Cables The High Speed Specific Trigger Fired Signals are delivered in 4 groups of 16 signals. These four cables provide a separate line for each of the Specific Triggers, with each group accompanied by a Strobe signal. All Signals are differential ECL pairs. The occurrence of the strobe signal indicates that at least one of the First Level Specific Triggers has fired. The raising edge of this strobe signal, called First Level Trigger Strobe, can be used to generate an interrupt in a Level 2 or Level 3 Trigger Computer. This strobe signal is between 900 nsec and 1100 nanosecond long. The First Level Trigger Strobe will be sent from the Trigger Framework 3.560 microsecond + or - 10 nsec after a Beam Crossing that results in a Level 1 Trigger Accept. The falling (trailing) edge of the First Level Trigger Strobe can be used to clock a latch at the Receiving End of the cables to capture the Specific Trigger Fired Mask. Data on these two cables will remain stable until the next First Level Trigger Strobe. All signals are differential ECL levels carried over 34 conductor twisted-flat cables with the non-inverted signal connected to the odd-numbered pins, and corresponding inverted signal connected to the following even-numbered pin. The first pair of conductors (pins 1 & 2) of a given cable carry the first Specific Trigger Fired Signal of the group while the last pair of conductors (pins 33 & 34) carry the Strobe Signal (???). At the Receiving End the cable must be terminated with a 110 Ohm resistor across each differential pair of lines. The Sending End (i.e. the Level 1 Trigger Framework) provides the pull down resistors to Vtt. SPECIFIC TRIGGERS FIRED CABLE NUMBER 1 ---------------------------------------- PIN # CABLE COLOR SIGNAL POLARITY ------- ------------- -------- ---------- 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED 1 BROWN SPECIFIC TRIGGER # 0 NON-INVERTED 2 TAN SPECIFIC TRIGGER # 0 INVERTED 3 RED SPECIFIC TRIGGER # 1 NON-INVERTED 4 TAN SPECIFIC TRIGGER # 1 INVERTED 5 ORANGE SPECIFIC TRIGGER # 2 NON-INVERTED 6 TAN SPECIFIC TRIGGER # 2 INVERTED 7 YELLOW SPECIFIC TRIGGER # 3 NON-INVERTED 8 TAN SPECIFIC TRIGGER # 3 INVERTED 9 GREEN SPECIFIC TRIGGER # 4 NON-INVERTED 10 TAN SPECIFIC TRIGGER # 4 INVERTED 11 BLUE SPECIFIC TRIGGER # 5 NON-INVERTED 12 TAN SPECIFIC TRIGGER # 5 INVERTED 13 VIOLET SPECIFIC TRIGGER # 6 NON-INVERTED 14 TAN SPECIFIC TRIGGER # 6 INVERTED 15 GREY SPECIFIC TRIGGER # 7 NON-INVERTED 16 TAN SPECIFIC TRIGGER # 7 INVERTED 17 WHITE SPECIFIC TRIGGER # 8 NON-INVERTED 18 TAN SPECIFIC TRIGGER # 8 INVERTED 19 BLACK SPECIFIC TRIGGER # 9 NON-INVERTED 20 TAN SPECIFIC TRIGGER # 9 INVERTED 21 BROWN SPECIFIC TRIGGER #10 NON-INVERTED 22 TAN SPECIFIC TRIGGER #10 INVERTED 23 RED SPECIFIC TRIGGER #11 NON-INVERTED 24 TAN SPECIFIC TRIGGER #11 INVERTED 25 ORANGE SPECIFIC TRIGGER #12 NON-INVERTED 26 TAN SPECIFIC TRIGGER #12 INVERTED 27 YELLOW SPECIFIC TRIGGER #13 NON-INVERTED 28 TAN SPECIFIC TRIGGER #13 INVERTED 29 GREEN SPECIFIC TRIGGER #14 NON-INVERTED 30 TAN SPECIFIC TRIGGER #14 INVERTED 31 BLUE SPECIFIC TRIGGER #15 NON-INVERTED 32 TAN SPECIFIC TRIGGER #15 INVERTED 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED SPECIFIC TRIGGERS FIRED CABLE NUMBER 2 ---------------------------------------- PIN # CABLE COLOR SIGNAL POLARITY ------- ------------- -------- ---------- 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED 1 BROWN SPECIFIC TRIGGER #16 NON-INVERTED 2 TAN SPECIFIC TRIGGER #16 INVERTED 3 RED SPECIFIC TRIGGER #17 NON-INVERTED 4 TAN SPECIFIC TRIGGER #17 INVERTED 5 ORANGE SPECIFIC TRIGGER #18 NON-INVERTED 6 TAN SPECIFIC TRIGGER #18 INVERTED 7 YELLOW SPECIFIC TRIGGER #19 NON-INVERTED 8 TAN SPECIFIC TRIGGER #19 INVERTED 9 GREEN SPECIFIC TRIGGER #20 NON-INVERTED 10 TAN SPECIFIC TRIGGER #20 INVERTED 11 BLUE SPECIFIC TRIGGER #21 NON-INVERTED 12 TAN SPECIFIC TRIGGER #21 INVERTED 13 VIOLET SPECIFIC TRIGGER #22 NON-INVERTED 14 TAN SPECIFIC TRIGGER #22 INVERTED 15 GREY SPECIFIC TRIGGER #23 NON-INVERTED 16 TAN SPECIFIC TRIGGER #23 INVERTED 17 WHITE SPECIFIC TRIGGER #24 NON-INVERTED 18 TAN SPECIFIC TRIGGER #24 INVERTED 19 BLACK SPECIFIC TRIGGER #25 NON-INVERTED 20 TAN SPECIFIC TRIGGER #25 INVERTED 21 BROWN SPECIFIC TRIGGER #26 NON-INVERTED 22 TAN SPECIFIC TRIGGER #26 INVERTED 23 RED SPECIFIC TRIGGER #27 NON-INVERTED 24 TAN SPECIFIC TRIGGER #27 INVERTED 25 ORANGE SPECIFIC TRIGGER #28 NON-INVERTED 26 TAN SPECIFIC TRIGGER #28 INVERTED 27 YELLOW SPECIFIC TRIGGER #29 NON-INVERTED 28 TAN SPECIFIC TRIGGER #29 INVERTED 29 GREEN SPECIFIC TRIGGER #30 NON-INVERTED 30 TAN SPECIFIC TRIGGER #30 INVERTED 31 BLUE SPECIFIC TRIGGER #31 NON-INVERTED 32 TAN SPECIFIC TRIGGER #31 INVERTED 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED SPECIFIC TRIGGERS FIRED CABLE NUMBER 3 ---------------------------------------- PIN # CABLE COLOR SIGNAL POLARITY ------- ------------- -------- ---------- 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED 1 BROWN SPECIFIC TRIGGER #32 NON-INVERTED 2 TAN SPECIFIC TRIGGER #32 INVERTED 3 RED SPECIFIC TRIGGER #33 NON-INVERTED 4 TAN SPECIFIC TRIGGER #33 INVERTED 5 ORANGE SPECIFIC TRIGGER #34 NON-INVERTED 6 TAN SPECIFIC TRIGGER #34 INVERTED 7 YELLOW SPECIFIC TRIGGER #35 NON-INVERTED 8 TAN SPECIFIC TRIGGER #35 INVERTED 9 GREEN SPECIFIC TRIGGER #36 NON-INVERTED 10 TAN SPECIFIC TRIGGER #36 INVERTED 11 BLUE SPECIFIC TRIGGER #37 NON-INVERTED 12 TAN SPECIFIC TRIGGER #37 INVERTED 13 VIOLET SPECIFIC TRIGGER #38 NON-INVERTED 14 TAN SPECIFIC TRIGGER #38 INVERTED 15 GREY SPECIFIC TRIGGER #39 NON-INVERTED 16 TAN SPECIFIC TRIGGER #39 INVERTED 17 WHITE SPECIFIC TRIGGER #40 NON-INVERTED 18 TAN SPECIFIC TRIGGER #40 INVERTED 19 BLACK SPECIFIC TRIGGER #41 NON-INVERTED 20 TAN SPECIFIC TRIGGER #41 INVERTED 21 BROWN SPECIFIC TRIGGER #42 NON-INVERTED 22 TAN SPECIFIC TRIGGER #42 INVERTED 23 RED SPECIFIC TRIGGER #43 NON-INVERTED 24 TAN SPECIFIC TRIGGER #43 INVERTED 25 ORANGE SPECIFIC TRIGGER #44 NON-INVERTED 26 TAN SPECIFIC TRIGGER #44 INVERTED 27 YELLOW SPECIFIC TRIGGER #45 NON-INVERTED 28 TAN SPECIFIC TRIGGER #45 INVERTED 29 GREEN SPECIFIC TRIGGER #46 NON-INVERTED 30 TAN SPECIFIC TRIGGER #46 INVERTED 31 BLUE SPECIFIC TRIGGER #47 NON-INVERTED 32 TAN SPECIFIC TRIGGER #47 INVERTED 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED SPECIFIC TRIGGERS FIRED CABLE NUMBER 4 ---------------------------------------- PIN # CABLE COLOR SIGNAL POLARITY ------- ------------- -------- ---------- 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED 1 BROWN SPECIFIC TRIGGER #48 NON-INVERTED 2 TAN SPECIFIC TRIGGER #48 INVERTED 3 RED SPECIFIC TRIGGER #49 NON-INVERTED 4 TAN SPECIFIC TRIGGER #49 INVERTED 5 ORANGE SPECIFIC TRIGGER #50 NON-INVERTED 6 TAN SPECIFIC TRIGGER #50 INVERTED 7 YELLOW SPECIFIC TRIGGER #51 NON-INVERTED 8 TAN SPECIFIC TRIGGER #51 INVERTED 9 GREEN SPECIFIC TRIGGER #52 NON-INVERTED 10 TAN SPECIFIC TRIGGER #52 INVERTED 11 BLUE SPECIFIC TRIGGER #53 NON-INVERTED 12 TAN SPECIFIC TRIGGER #53 INVERTED 13 VIOLET SPECIFIC TRIGGER #54 NON-INVERTED 14 TAN SPECIFIC TRIGGER #54 INVERTED 15 GREY SPECIFIC TRIGGER #55 NON-INVERTED 16 TAN SPECIFIC TRIGGER #55 INVERTED 17 WHITE SPECIFIC TRIGGER #56 NON-INVERTED 18 TAN SPECIFIC TRIGGER #56 INVERTED 19 BLACK SPECIFIC TRIGGER #57 NON-INVERTED 20 TAN SPECIFIC TRIGGER #57 INVERTED 21 BROWN SPECIFIC TRIGGER #58 NON-INVERTED 22 TAN SPECIFIC TRIGGER #58 INVERTED 23 RED SPECIFIC TRIGGER #59 NON-INVERTED 24 TAN SPECIFIC TRIGGER #59 INVERTED 25 ORANGE SPECIFIC TRIGGER #60 NON-INVERTED 26 TAN SPECIFIC TRIGGER #60 INVERTED 27 YELLOW SPECIFIC TRIGGER #61 NON-INVERTED 28 TAN SPECIFIC TRIGGER #61 INVERTED 29 GREEN SPECIFIC TRIGGER #62 NON-INVERTED 30 TAN SPECIFIC TRIGGER #62 INVERTED 31 BLUE SPECIFIC TRIGGER #63 NON-INVERTED 32 TAN SPECIFIC TRIGGER #63 INVERTED 33 VIOLET FIRST LEVEL TRIGGER STROBE NON-INVERTED 34 TAN FIRST LEVEL TRIGGER STROBE INVERTED Appendix C L1 Trigger Framework Data Block -------------------------------------------------------------------------------- More Questions: 1) do we want to give COOR the responsibility of the list of which Geographic Section Errors should be listened to, or is that implicit from the list of Geographic Sections used in the current programming. 2) Do we want to give COOR the responsibility of the list of FIFO delays per And-Or Term, or is it a file we want to leave on TCC. 3) Should the Beam Crossing where a FIFO error is detected be prevented from generating and event. Should we make that a global disable line and an option for a Specific trigger to listen to. 4) is there a reload (download FPGA) message separate from the Initialize (program registers) message 5) see point risen in 10.c. 6) do we talk (and where) about the D0 master clock signals we get? 7) can we define how we distribute the spec trig groupings?