The Level 1.5 Trigger Framework 29-OCT-1991 11-NOV-1991 13-NOV-1991 18-NOV-1991 21-NOV-1991 3-DEC-1991 10-DEC-1991 5-JUN-1992 9-JUN-1992 29-JUN-1992 Introduction ------------ The Level 1 Trigger Framework is designed to examine the information presented by the various Level 1 Triggers (e.g. the Level 1 Calorimeter Trigger, the Level 1 Muon Trigger, and the Level 0 Trigger), and form the 32 Specific Trigger Fired #i decisions and 32 Start Digitize Geographic Section #j signals between beam crossings. The Level 1 Trigger Framework is therefore designed to cause zero dead time in the process of firing Specific Triggers. Some classes of physics information, or triggers, are not available between beam crossings. Specifically, the Muon Level 1.5 Trigger and TRD Level 1.5 Trigger require more processing time than is available between beam crossings. The Level 1.5 Trigger Framework is a mechanism for including these classes of information in the Level 1 Trigger Framework decisions, at the expense of introducing dead time into the Level 1 Trigger decisions. The Level 1.5 Trigger Framework is the system which processes Specific Triggers which are programmed by COOR to require Level 1.5 confirmation. It decides whether to begin a Level 1.5 Cycle, controls the Level 1 Trigger Framework during Level 1.5 Cycles, and decides when to end a Level 1.5 cycle. It also receives and interprets the information from the Level 1.5 Trigger Subsystems, and conveys the results (e.g. Level 1.5 Confirmation for Specific Trigger #i or Level 1.5 Veto for Specific Trigger #i) to the Level 1 Trigger Framework. The Level 1.5 Trigger Framework is a general-purpose service provided for triggering. It has a simple communication mechanism with the Level 1.5 Trigger Subsystems, and is extensible to Level 1.5 Trigger Subsystems beyond those which currently exist. Important Considerations ------------------------ Since the Level 1 Trigger Framework would ideally be a zero dead time system, we naturally wish to minimize the dead time introduced by the Level 1.5 Trigger Framework Expansion. We also wish to pass a reasonable Trigger Mask to the Level 2 Processor Farm, so that it can apply the appropriate filters. Physics quantities like acceptance must be recoverable. Some form of time out (arbitrarily chosen to be 200 microseconds, or twice a typical Level 1.5 cycle) must be present, to end the Level 1.5 Cycle if one or more terms are neither confirmed nor denied within a reasonable span of time. To limit dead time, the design philosophy of the Level 1.5 Trigger Framework Expansion is "Events will be passed (i.e. the Level 1 Trigger will cycle the data acquisition subsystems) as soon as a reason to do so is found." In operational terms, this means the following: 1. We will let events pass if at least 1 pure Level 1 Specific Trigger has fired, even if one or more Level 1.5 Specific Triggers has fired and would "normally" require confirmation. 2. We will let events pass at the first positive Level 1.5 Specific Trigger confirmation, even if other Level 1.5 decisions are pending or have been confirmed rejected. We will wait for ALL negative Level 1.5 Specific Trigger confirmations before discarding the event. 3. If Level 1.5 "times out," we will let the event pass. Of the 32 Specific Triggers, only a fixed set of 16 are allowed to request Level 1.5 confirmation. For any of the 16 Level 1.5-capable Specific Triggers, any number of Level 1.5 Terms can be included in the confirmation. When multiple Level 1.5 Terms are required for a given Level 1.5 Specific Trigger confirmation, ALL required Terms must be confirmed accepted. That is, the Specific Trigger requirements are the AND of all specified Level 1.5 Terms. Note that only positive Level 1.5 Term confirmations can be required in a Level 1.5 Specific Trigger. Additionally, the Level 1 Trigger Framework should have, as much as possible, the ability to ignore the Level 1.5 Trigger Framework as desired. This is useful for times when the Level 1.5 Trigger Framework is unavailable (e.g. powered-off or faulty). In practice, the Level 1 Trigger Framework has the ability to ignore all signals from the Level 1.5 Trigger Framework with the notable exception of the Level 1.5 VETO signals which directly enter the FSTD cards as AND-OR inputs (NOT as AND-OR Terms to the IML cards). When the Level 1.5 Trigger Framework is powered-off, these signals reliably default to a harmless state (that is, to NOT VETOING the Level 1 Specific Trigger). If, however, the Level 1.5 Trigger Framework is powered-on, these signals may be driven to any state. Therefore, the cable communicating these signals to the Level 1 Trigger Framework must be disconnected from the Patch Panel if the VETO signals are not to influence the Level 1 Trigger decision. WHAT ABOUT L15 SCALERS IN THE M114 BACKPLANE? IS THERE ANYTHING ELSE WHICH IS NOT CONTROLLED? Block Diagram ------------- See L15_DIAGRAMS.TXT for a drawing of the Level 1.5 Trigger Framework block diagram. Implementation -------------- The Level 1.5 Trigger Framework Expansion is designed around pre-existing Level 1 Trigger Framework Application Cards, in order to reduce the design time required. This places some limitations on the kinds of processing that can be performed. Receiving MTG For each Level 1.5 term, two signals are presented to the Receiving MTG: ANSWER #i and DONE #i. The two signals are time-division multiplexed into a single output line per Level 1.5 term. This MTG requires modification, but maintains the ability to inject test signals via the CBUS. Receiving TLM/Fanout Each of the 32 MTG outputs is fanned-out 4 times using a TLM/Fanout card. This will produce 128 signals, which fills a Level 1.5 Framework Expansion Backplane Bus. This is done in Transparent mode. Answer/Done DGM's Four Answer/Done DGM's listen to the time multiplexed Level 1.5 Term ANSWER/DONE signals on the Backplane. Each of the four channels on the DGM produces the time-multiplexed ANSWER/DONE signal for one of the 16 Level 1.5-capable Specific Triggers. Note that this time-multiplexed ANSWER/DONE signal will be present whether or not the particular Specific Trigger was fired, because there is no way to include the Specific Trigger Fired information in real-time, due to the limitations of using a DGM. These are ordinary DGMs. Veto/Confirm MTG A single MTG listens to the Answer/Done DGM's. Each MTG channel corresponds to either the Level 1.5 Veto signal or the Level 1.5 Confirmation signal for a single Level 1.5 Specific Trigger. The VETO signal is asserted if and only if: 1) The Level 1.5 Specific Trigger met all its Level 1 requirements, and 2) At least one Level 1.5 Term defined for this Level 1.5 Specific Trigger has been confirmed rejected The CONFIRM signal is asserted if and only if: 1) The Level 1.5 Specific Trigger met all its Level 1 requirements, and 2) All Level 1.5 Terms defined for this Level 1.5 Specific Trigger have been confirmed accepted This MTG requires modification similar to the L1.5 Receiving MTG, and maintains the ability to inject test signals via the CBUS. Answer/Done/Control IMLRO A single IMLRO listens to the 32 L1.5 Answer, 32 L1.5 Done, 16 L1.5 Specific Trigger Veto, 16 L1.5 Specific Trigger Confirm, and 32 Level 1.5 Control MTG output signals. This IMLRO has 4 clocks, allowing 4 different classes of information to be latched at 4 different times. Thus a modified IMLRO is used. Control Signal DGMs A DGM will generate four important control signals: 1) At least one pure Level 1 Specific Trigger Fired 2) At least one Level 1.5 Specific Trigger Fired 3) At least one Level 1.5 Specific Trigger Confirmed Accepted 4) At least one TRD Level 1.5 Specific Trigger Fired These signals will be passed to the Level 1.5 Control MTG. Control Signal MTG This MTG is isochronous with the Framework Main Timing MTG. It receives inputs from the Control Signal DGM. It produces gated, usable, synchronous control signals for the Level 1.5 Trigger, and ungated logical functions of the Control Signal DGM outputs. It is an ordinary MTG, but several functions require cascading 2 or more MTG channels. IMPORTANT OUTSTANDING QUESTIONS/COMMENTS: ---------------------------------------- 1. Is it reasonable to clock the Veto/Confirm MTG PALs? Having a clocked PAL makes things _much_ easier, although I think I might be able to do something bizarre to make the thing work. ---> CLOCKED looks OK, think about "asynch" clock PALs (AMD 16RA8) 2. Current thought with respect to VETO is: Generate all Level 1.5 ST Rejected by looking at output of FSTD. This means FSTD must be clocked all through L1.5 cycle at some rate. VETO MTG should know the state of each L1.5 Specific Trigger (whether or not it has fired), and only generate VETOs for L1.5 Specific Triggers that have fired. VETO would stay LOW for all unfired L1.5 Specific Triggers. What about scalers in this situation? Philippe and I have talked about various VETO architectures, this one looks most promising to me. ---> looks OK 3. L1.5 processing may continue after decision has been made (in the case of confirmation). The Answer/Done IMLRO must be not be latched after the Term Cycle which forced the confirmation. ---> only 1 full cycle will occur, easy to mask IMLRO clock 4. Due to the nature of the MTGs used, reset will not occur until one entire L1.5 cycle period after the "L1.5 Cycle in Progress" falling edge indicating logical completion of the cycle. This is actually an advantage, and the "Veto" and "Confirm" signals are then held to allow latching in the IMLRO. If they weren't held past the logical end of the cycle, latching would be more difficult (as the Specific Trigger Mask must be latched after the end of the cycle). ---> "reset" argument NOT TRUE, latching will be OK also. see timing diagram. 5. How finely should we do the mapping of Level 1.5 Specific Trigger to Level 1.5 Term? That is, can we fire Term #13, or should/must we fire ALL MUON and/or ALL TRD whenever some MUON and/or some TRD are required? ----> Philippe: MUON doesn't need any go signal. We will use sections of a (new) DGM as needed for TRD,... 6) Does the muon system provide in its zebra data enough information for the level 2 to verify that a given LV1.5 SpTrg was indeed confirmed accepted? 7. This scheme requires one timing signal from the FWMTG, called L1.5 MASTER CLOCK. That will be the master clock for the L1.5 Control MTG. The L1.5 Control MTG then generates the other needed timing signals. However, the Receiving MTG and the Done/Data MTG generate a timing signal for internal use, which is identical to a timing signal generated on the Control MTG. Care is taken to maintain synchrony by gating the L1.5 CYCLE IN PROGRESS signal, but I am still a bit concerned about maintaining synchrony. ---> synchrony OK, 2 signals from FWMTG. 8. The Level 1.5 Control Signal MTG may not 'rollover' its PROM, or the L1.5 CYCLE IN PROGRESS signal would be corrupted. This places an upper limit on the frequency of the L1.5 MASTER CLOCK. A lower limit is placed on this frequency by the desire to capture signals of short duration from the Level 1.5 subsystems (a signal must be asserted for at least one complete period of the L1.5 MASTER CLOCK to guarantee capture in certain architectures). Having a L1.5 Master Clock period of 1 between-bunch period, and with a controlled phase with respect to the beam crossing marker, has advantages. Note that, once the L1.5 decision has been made, L1.0 response has beam crossing time dependence (e.g. Hold Transfer/Start Digitize falling edges). 9. L1.5 Write A/B should always be the opposite of L1.0 Write A/B, because the L1.5 information is generated AFTER the Start Digitize, while the L1.0 information is generated BEFORE the Start Digitize. L1.5 Read A/B should always be identical to L1.0 Read A/B, to associate the L1.5 information with the correct L1.0 information in the Data Block. See timing diagram. 10. Two architectures for L1.5 Receiving MTG have been proposed. Others are possible. We should try to have MUON people tell us their control signal timing, which will help us choose architecture. ---> MUON has note. 11. Currently, we are deaf to L1.5 Terms/Dones for the up to 2 full cycles of the Master Clock (beam crossing rate?) at the beginning of the L1.5 Cycle. Can we expect L1.5 Terms/Dones to appear (and disappear) in this time? This is because I wish to gate the L1.5 Cycle in Progress line to guarantee that it does not occur near the FWMTG Master Clock. L1.5 Cycle in Progress can only go high shortly after the beam crossing marker, so we could also require the FWMTG Master Clock to be steady in the region of the beam crossing marker (simple if a low frequency clock), but this causes problems reading out the VETO and CONFIRM at the end of the cycle. ---> NOT TRUE 12. Which Specific Trigger Mask is recorded in the SpTrig Mask location of the Data Block? We must record the other in a new location (referring to pre/post L1.5 cycle). ---> pre-L1.5 in Data Block now, post-L1.5 needs home, way to get there.