Level 2 Trigger Framework Helper Functions Design ----------------------------------------------------- Original Rev. 11-JUN-1999 Latest Rev. 8-MAR-2000 The purpose of this file is to describe the design of the L2 Framework and the Helper Function. The intent is to describe the overall operation of these objects. Because the "control path" connection to the Level 3 "Supervisor" is part of the Level 2 Trigger Framework, this document includes a description of its operation. Control of the L2 FW involves two basic ideas: L2 FW has "States" and will be controlled by a State Engine. This is different than the L1 FW which is basically stateless. The general control idea is to gather up all of the information needed to distribute a given L2 Decision and then wait for a "non L1 Accept" SCL Frame to accomplish this distribution. The general view of the L2 Framework shows that it is connected to the following systems: +----------+ L1 Framework --> | | | | --> SCL Hub End L2 Global Proc --> | L2 | | Frame | Master Clock --> | Work | | | --> L3 Supervisor SCL Hub End --> | | +----------+ | | | -----> Monitor Data Readout The signals involved in the Level 2 Framework can be categorized as either a Data Path or Control Path signals. The Data Path signals will be listed here. The Control Path signals are described in a latter section about the L2 Helper Function. L2 Framework Data Path Signals ------------------------------ Inputs to the Outputs from the Level 2 Framework Level 2 Framework ------------------------ ------------------------------ L1 Spec Trig's List of Geo Sections that Fired List (128) are to Accept this Event (128) Answers from the List of Geo Sections that Level 2 Global (128) are to Reject this Event (128) Level 1 Geo Section List of L1 Spec Trig's that Trigger Number were Passed by L2 (128) Associated with (Sent to L3 Supervisor) the L2 Decision (24) Associated L1 Geo Section Level 3 Transfer Trigger Number (24) Number Associated (Sent to L3 Supervisor) with the L2 Decision (16) Associated L1 Geo Section Trigger Number (24) Level 2 Busy Signals (Sent to SCL Hub-End) from the Front-Ends (128) Associated L3 Transfer Number (16) Auxiliary Data from L1 (Sent to L3 Supervisor) up to 64 bits of data Currently L1 Qualifier Cap Mon Data is the Associated L3 Transfer only signal uses. It Number (16) is described in the (Sent to SCL Hub-End) the Control Signal section of this note. Review of the Context and Ground Rules In Which the L2 FW Will Operate ---------------------------------------------------------------------- 1. Coordination with the L2 Global Processor. We started out thinking of a setup where: L2 FW guarantees to the L2 Global System that within ?X? usec of receiving new "L2 Global Answer Data", the L2 FW will have distributed via the SCL the results of this L2 decision. and The L2 Global System guarantees to the L2 FW that L2 Global will not send consecutive packets of "L2 Global Answer Data" to the L2 FW closer together than ?X? usec. But this is now all just junk. We need to be able to buffer the "L2 Global Answer Data" from the L2 Global Processor because we can not control the rate of transport of events up to L3 and thus we may not be able to distribute an L2 Decision right away. 2. Operation when a Geo Section says that it is Level 2 Busy Geographic Sections have only 8 buffers to hold events that have been passed by Level 2 and are now awaiting their turn to transport to Level 3 via the VBD and Data Cable. When a given Geo Section has all 8 of these buffers in use then it can not be sent any additional L2 Accept Decisions. The Geo Section reports the fact that all 8 of its buffers for holding events awaiting their turn to transport to L3 are currently full via the L2 Busy Signal that it sends back to the Trigger Framework. It is the responsibility of the Trigger Framework not to send out any L2 Decisions that include sending a L2 Accept to a Geo Section that is currently L2 Busy. So the Framework can be in the position of not being able to distribute L2 Decisions while at the same time it is receiving additional L2 Answers from the L2 Global processor. Thus the Framework is required to FIFO buffer the answers that it receives from the L2 Global processor. When thinking about the required size of this FIOF it becomes clear that 16 stages is enough because at that point some front end will run out of places to hold events awaiting their L2 Decision, and thus L1 Accepts will stop, and thus we will quit receiving Answers from L2 Global. When one or more Geographic Section, that are part of the current running system, is asserting L2 Busy then the Framework must not distribute via the SCL any L2 Decisions that involve telling these Geo Section to Accept the event and transport it to Level 3. However during this period, where one or more Geo Sections are L2 Busy, Framework needs to continue to distribute L2 Decisions that tell these Geo Sections to Reject the event. Note they system will be "partitioned" with respect to L2 Busy just as it is with L1 Busy. That is when some Geo Section is L2 Busy, L2 Decisions may include distributing L2 Accepts just so long as they do not involve the Geo Sections that are L2 Busy. 3. After a period where the L2 Global Answer FIFO has stored up a number of L2 Answers the L2 FW will have to itself control the rate that it distributes these answers via the SCL. 4. Coordination with the L3 Supervisor The L2 FW may push Data to the L3 Supervisor at the maximum rate that it is allowed to distribute L2 Decisions via the SCL. The L2 FW must guarantee to the L3 Supervisor that it will send Data to L3 within ?X? usec of distributing via the SCL a L2 Decision that includes instructing one or more Geo Sections to readout. 5. Fine Points L2 FW should send control information to Level 3 only if L2 Global has passed at least one of the Spec Trig's that fired at Level 1. Or should it be that control information is sent to L3 only if one or more of the Geo Sections is actually given a L2 Accept Decision, i.e. we know that there is something to be readout to L3. That is should we allow for L1 Spec Trig's that are not connected to any Geo Sections. The way the L2 FW is being built is that it will send control data to the L3 if any of the Spec Trig's that fired at L1 are passed by L2. To make up "Spec Trig's" just for monitoring something special, and not connected to any Geo Sections, use the "Diagnostic - Monitoring" facility of the Exposure Group And-Or Cards. 6. Startup and Required Actions at SCL Initialize Time When the L2 FW is started up it will be necessary to empty all of the data out of its input TRM FIFO's and the FIFO in the T&T Scaler that stores the Geo Sec L1 Trig Num's of the L1 Accepts. With every SCL Initialize these FIFO's will also have to be emptied. It is assumed that TCC will be involved in this, probably at the level of telling the L2 FW Helper to emptly the L2 FW Input FIFO's. 7. Modes of operation The L2 FW must have 3 distinct modes of operation. These are briefly described in the following: Normal Mode - This is used for normal Physics Running where the L2 FW receives Answers from the L2 Global Stage. ByPass Mode - This could be used for Physics Running but is more likely used for Calib's and such between Accelerator Stores. This mode does not use Answers from L2 Global stage. The answer that the L2 FW will use for each occurrence of a given L1 Spec Trig is loaded into it via TCC before the run starts. Once the system is running, TCC is not involved in the event to event operation. Test Mode - This mode is used only for exercise and diagnostics of the L2 FW. We probably want to think of the L1 FW as giving test vectors to the L2 FW. Very likely when in this mode, TCC is involved in the processing of each event through the L2 FW. FIFO's in the F2 FW ------------------- A number of FIFO's are used to buffer/store the input data to the L2 FW. All of these FIFO's should have some common features. Must give them a read clock to get the first piece of data to come out. Do not need to worry about FIFO over run. Other Things are protecting us. Need to empty all of these FIFO's when we initialize. We assume that all the FIFO's will stay in sync. All the L2 FW Input TRM's run from the FW Tick Clk and not from the TRM Clk. Control Signals from the L2 FW Helper Function ---------------------------------------------- Where possible the control signals coming out of the L2 FW Helper Function will be in the form of "enables" and not in the form of actual "clocks" going to edge sensitive logic functions. Control Scheme aka the L2 FW Helper Functions --------------------------------------------- This control scheme is based on 396 running where 2 out of every 3 SCL Frames are available for distribution of L2 Decisions. As will become apparent, moving over to a scheme where you do not know ahead of time what SCL frames can be used for L2 Decisions is not complicated, it just not doable. A description follows for each of the Control Signals used in the L2 FW, Note that for normal L2 FW operation most of these Control Signals are used by or generated by the L2 FW State Engine. However, there are a few additional Control Signals that are used by or generated by the L2 FW Helper Function that are not envolved with the State Engine in this helper function. L2 FW Control Signals --------------------- Rev. 2-DEC-1999 First is just a list of the L2 FW Control Signals - this is followed by a description of each one: Write Clk to TRM and T&T SM TRM Read Enable Send L2 Decision Distributing L2 Decision L3 Control Data Latch Enable L3 Data Strobe & Increment L3 Transfer Number L2 FW Capture Monitor Data L2 FW Maginot Line L1 Accept Qualifier, Capture Monitor Data for this Event L2 Answers FIFO Not Empty L1 Spec Trig's Fired Mask FIFO Not Empty L2 BAD Outputs Send to L3 Required Write Clock to the L2 Answer TRM FIFO's First describe the L2 FW Control Signal that go to more than one destination. Write Clk to TRM and T&T SM This signal is made by the FOM++, it is the "latched" L1 Fired Strobe. That is it is updated by the Tick Clk. It is used as a Write Clk by the TRM FIFO's that hold the L1 Spec Trig Fired Mask and Auxiliary Data It is used as a Write Enable by the FIFO in the Geo Sect L1 Trig Num Tick & Turn Scaler card. Because of data hold time constraints to the TRM's (i.e. the Mask of L1 Spec Trig's Fired starts to go away soon after the L1 Fired Strobe is generated) we do not have time to process this signal in the L2 FW Helper. So we will use a direct hardware fanout. 8 copies to the TRM's for Mask of Spec Trig's Fired, 4 copies to the TRM for Aux Data, and 1 copy to the T&T Scaler. The copy to the T&T scaler will have about 30 nsec of cable delay to make it into a Clock Enable type signal. This enters the Geo Sect L1 Trig Num T&T Scaler on its MSA_In_0 The L1 FW Accept Strobe comes from the FOM++ MSA_Out_(43:40) and is a latches signal updated by FW Tick Clk. We will use MSA_Out_43 for this application. Recall the extent to which there is some what programmable about when this signal will occur (i.e. in response to what sub set of L1 Spec Trig's Firing) because this signal is generated by the FOM++. TRM Read Enable Is this a clock enable type signal that is made by the L2 FW Helper. This signal is used by the 5 TRM's at the input to the L2 FW. Note that these 5 L2 FW Input TRM's run on the FW Tick Clk and not on the TRM Clk. This signal is needed in two crates, M122 Bot and M123 Mid The L2 Helper should make two copies of this signal. The current plan is to use P1_TS_13 to distribute this signal. Currently this P1_TS is called "Transfer Mask to L2". On these L2 FW Input TRM cards we do not need the GAP signal so on these cards the BSF FPGA would route P1_TS_13 on the HQ Timing Line that is used for the GAP signal in the L1 FW applications. So this would require the TRM to grow a mode control bit. This is option #1 in Steve's 4-NOV-1999 note. Send L2 Decision This is a Clock Enable type signal that is made by the L2 FW Helper. It is on P1_TS_14 and is needed in the M123 Mid and Bot crates. It is used by the Geo Section L1 Trig Num T&T Scaler and by the FOM++. The L2 FW Helper will directly make the Helper Clock "latched" version of this signal that goes to the SCL Hub-End i.e. the "Distributing L2 Decision" signal. Recall that Helper Clock in a helper is at the same time as Tick Clock in a "normal" MSA FPGA. The Send L2 Decision signal is also the signal that will most likely be used to decrement the up-down counter that keeps track of the number of events awaiting their L2 Decisions. So we need a 3rd copy. We would like the L2 Helper to make three copies of this signal plus the "latched" version of it, i.e. the Distributing L2 Decision signal. L3 Control Data Latch Enable This is a Clk Enable type signal. It is made by the L2 FW Helper. It goes to the FM-Latch cards that hold Control Data that may be sent to L3. This signal is asserted in the "tick" following the tick that has Send L2 Decision asserted. The idea is to cycle this during all L2 FW Cycles. Thus the Control Data being sent to L3 will change near the end of each L2 FW Cycle but we only give L3 a Strobe, telling it to absorb a new "word" of Control Data for L2 Decisions that result in requiring the readout of one or more Geo Sections. This signal is needed both in the M122 Bottom crate and the M123 Bottom crate. The current plan is to distribute this signal on P1_TS_12 in these two crates. Note that in the M123 Mid crate that this P1_TS is carrying a different signal. See the next item. We want the L2 FW Helper to make two copies of the L3 Control Data Latch Enable signal, one for each crate. So the latch enable will reach the FM-Latch card on P1_TS_12. We still need to figure out which HQ TS the FM-Latch card should use for its Tick Clk, Latch Enable, and Capture Monitor Data signals. L3 Data Strobe and Increment L3 Transfer Number This is a Clk Enable type of signal made by the L2 FW Helper. It is used to Increment the L3 Transfer Number in the FOM++ and is the new data strobe send to L3. This signal is distributed to the M123 Mid crate on P1_TS_12. Note that in crates M122 Bot and M123 Bot this P1_TS is used to distribute a different signal. See above. This signal enters the FOM++ on P1_TS_12 to Increment the L3 Transfer Num. The L2 FW Helper should make 2 copies of this signal (and possible 3 copies if we want to count the number of time that we have told L3 that it has some work to do). This signal is asserted only for those L2 FW Cycles that are advertizing that there are some L1 Spec Trig's that were passed by L2 Global and thus there are some Geo Sections that need to be readout by L3. It is asserted a couple of micro seconds after the L3 Control Data Latch Enable signal. This give the control data going to L3 plenty of time to settle down before L3 is told to ingest this new control data. L2 FW Capture Monitor Data This signal is generated by the L2 FW Helper. The conditions under which it is generated is described below. It is used by basically all the cards in the L2 FW. In the M122 Bot crate this signal is distributed on P1_TS_10 to the bulk of the L2 FW. Note that in other crates this P1_TS carries a different signal, i.e. the L1 Fw Cap Mon Data signal. There are two other L2 FW locations that need to receive the L2 FW Capture Monitor Data signal The two TRM's in M123 Mid which FIFO the L1 Spec Trig Fired Mask will receive the L2 FW Cap Mon Data signal via their front panel P5 connector pins 1,2. From P5 this signal will flow to the BSF FPGA where it would begin its normal distribution into the Main Array FPGA's. The FM-Latch card in M123 Bottom which holds the L3 Trans Num and the Geo Sect L1 Trig Num Control Data going to Level 3 will receive the L2 FW Capture Monitor Data signal using the scheme described above for the M123 Mid TRM's, i.e. the L2 Capture Monitor Data will be received on this FM-Latch by its P5 connector pins 1,2. The Capture Monitor Data signal is issued for only some of the L2 FW Cycles. When issued it is issued near the very end of the cycle when all of the data used in that L2 FW Cycle is stable. The normal L1 FW History Shift Register is used for the L2 FW monitor data. This works because the L2 FW Cycle is long enough so that all slots in the History Shift Register just hold the same data. As with the L1 FW Cap Mon data signal there are two ways to generate the L2 FW Cap Monit Data signal. By writing to a register Philippe can cause the L2 FW Cap Monit Data to be generated immediately or Philippe can write something else to this control register which arms the L2 FW Helper for the following sequence of events. Enable the L2 Helper to generate the L2 FW Cap Monit Data signal the next time that the L2 FW is processing an event for which the "Capture Monitor Data" L1 Accept Qualifier is set - and Erase some VME readable latch that remembers if a L2 FW Cap Monit Data signal has been issued since it was last armed. So then the steps during normal physics running with Monitor Data being captured about once every 5 seconds would be: 1. Wait 5 seconds. 2. Arm the L2 FW Helper to generate a L2FW Cap Monit Data signal the next time that it processes an event that had the Cap Monitor Data L1 Qualifier set and clear its flag that says that there has been a L2 FW Cap Monitor Data signal. 3. Arm the L1 FW Helper so that on the next L1 Accept it will generate a L1 FW Cap Monitor Data signal and clear its flag that says there has been a L1FW Cap Monitor Data signal. 4. Spin on checking the "there has been a L1FW Cap Monit Data signal" flag until it is asserted. This should take about 100 usec when running at 10 kHz L1 Accept rate. Once this flag is set you may begin to read the L1 FW Monitor data via VME. 5. Check the "there has been a L2FW Cap Monitor Data signal" flag until it is set. Once this flag is set you may begin to read the L2 FW Monitor Data via VME. It should take about 800 usec for this flag to become set (guessing 8 events in L2 Trig System). L2 FW Maginot Signal This signal is made by the L2 FW Helper. It will possibly be used for the "test mode" and the "bypass mode" of the L2 FW. It goes to the L2 Answers TRM This enters these two TRM's on a P1 TS #11. For the L2 Answer TRM's this signal is needed only in the M122 Bot crate where this P1 TS is available. We will also route this signal to the M123 Mid TS #11 so that it is available to the TRM's that FIFO the list of L1 Spec Trig's fired just in case we also (for some testing) want these TRM's to also use the L2 FW Maginot signal. Note that this is a case where the same P1_TS i.e. P1_TS_11 is used to carry different signals in different crates and that we must be careful not to confuse the classic L1 FW Maginot line with this new L2 FW Maginot Line. For some testing purpose, it is conceivable that we will end up wanting to select a TRM Test Register on the Aux Data TRM or the L1 Spec Trig Fired Mask TRM's. For the Aux Data TRM there is no issue because it is in the same crate (M122 Bot) as the L2 Answer TRM. For the L1 Spec Trig Fired Mask TRM this should also be OK because it is in crate M123 Mid which currently does not use P1_TS_11. Because it is possible that we want this signal in 2 different crates the L2 FW Helper should make 2 copies of it, Now describe the L2 FW Control Signals that go to only one destination i.e. Single Signals List L1 Accept Qualifier (Capture Monitor Data for this Event) must be routed to the Aux Data TRM input and from the Aux Data TRM output to the L2 FW Helper. The L1 Accept Qualifiers are made by the FOM++ and there is already a "tap" on the cable taking these signals to the SCL Hub-End. This tap is for the FM-Latch that grabs the L3 Transfer Number. L2 Answers FIFO Not Empty Both of the TRM's that FIFO the answers from L2 Global make this signal. They should always agree with each other and there is nothing that L2 FW Helper could do to straighten things out if they do not agree. So we will route this signal from just one of the L2 Answer TRM's to the L2 FW Helper. L1 Spec Trig's Fired Mask FIFO Not Empty Both of the TRM's that FIFO this data make this signal. They should always agree with each other and there is nothing that L2 FW Helper could do to straighten things out if they do not agree. So we will route this signal from just one of the L1 Spec Trig's Fired Mask TRM's to the L2 FW Helper. L2 BAD Outputs This is a signal generated by the two L2 BAD cards. Each of the two L2 BAD cards will make multiple copies of its output signal. The principal destination for this signal is the L2 FW Helper. The output signals from these two cards are combined in the L2 FW Helper. These signals come from the front panel P4 MSA_Out connector on the two AONM's that provide the L2 Bad function. Which MSA_Outs ?? Note that each AONM makes multiple copies of its output signal and besides the copy going to the L2 FW Helper there are copies going to a scaler. Send to L3 Required This signal is generated by one of the L2 Accept FOM cards. It is asserted when >= 1 Spec Trig passed L2 and it means that Control Data must be sent to L3 near the end of this L2 FW Cycle. The plan is to use Geo Section #127 to generate this signal. This signal runs over to the L2 FW Helper. We want to tie the lines running over to the SCL Hub-End for this Geo Section L2 Accept to and Diff ECL Low. Could we get this from the front panel P5 connector on this FOM or would it be easier to get it from the L2 FW Helper ? Write Clock to the L2 Answer TRM FIFO's We get a strobe signal from L2 Global went it hands us a new set of answers. We need/want to pass this signal through the L2 FW Helper before giving it to the L2 Answer TRM's e.g. so that for testing we can guarantee that L2 Global is NOT putting data into this FIFO or so that we can put data into this FIFO to get the Not Empty signal asserted for testing or bypass mode (even if we are not using the data from the FIFO but rather data from a TRM Test Register Unless the L2 FW Helper has so many outputs available that it can easily make 8 copies of this signal then we will use a hardware Fan-Out of this signal to make enough copies of it 128/16 = 8 copies. Block Diagram of the L2 FW Helper Function ---------------------------------------------- Rev. 2-DEC-1999 Helper Function Clk >----------. | | | | L2 Answer FIFO +---------------+ Read Enable Not Empty >-----| |---/--> to the TRM's | | 2 L1 Spec Trig | | Fired FIFO >-----| | Send L2 Not Empty | |---/--> Decision | | 3 Interaction | | Marker from >-----| | Distributing Master Clk | L2 FW |---/--> L2 Decision | State | 1 L2 BAD from | Engine | the two >-/---| | L3 Control Data L2 BAD AONM's 2 | |---/--> Latch Enable | | 2 Send to L3 | | Required from >-----| | L3 Control Data L2 Accept FOM | |---/--> Strobe and Inc Geo Sect 127 | | 3 L3 Trans Num | | L1 Accept | | Qualifier | | Capture Mon >-----| |---/--> L2 FW Capture Data for this | | 3or4 Monitor Data Event from | | Aux Data TRM | | | |---/--> L2 FW Maginot +---------------+ 2 Signal | | | | V V +---------------+ Write Clk to the New Data from >-----| |---/--> L2 Answer TRM L2 Global Strb +---------------+ 1or8 FIFO's Not shown are any of the control/status registers that TCC uses to control the L2 FW Helper and to read the status of its various components. As show the L2 FW Helper has 10 inputs (this counts the 2 clock inputs and both L2 BAD inputs) and either 17 or 18 or 24 or 25 outputs depending on whether it makes 1 or 8 copies of the Write Clock to the L2 Answer TRM FIFO's and whether it makes 3 or 4 copies of the L2 FW Capture Monitor Data. Processing Flow of the L2 FW Helper, i.e. the L2 FW Cycle --------------------------------------------------------- Rev. 7-DEC-1999 This is a describes the L2 FW Cycle used to distribute L2 Decisions via the Serial Command Link. The L2 FW Cycle is controlled by the State Engine in the L2 FW Helper Function. The States generated by this State Engine are the steps in the L2 FW Cycle. The description of each step in the L2 FW Cycle will include a description of what the L2 FW is doing in that state and a description of the conditions the the State Engine must see before it moves to the next state. Recall that the L2 State Engine is clocked by the Helper Function Clock. This lets the outputs of the L2 State Engine directly serve as Clock Enable signals to the rest of the hardware in the L2 FW. Because the L2 FW has three different operating modes: Normal, ByPass, and Testing; the L2 FW State Engine must have a different set of states (or different path through the states) to implement these different modes. So far only the Normal and ByPass modes are understood. So the following description does not currently cover the Testing mode. 1. Initial state: The previous L2 FW Cycle has fully concluded including the "cool down" period at the end of L2 FW Cycle. This state is the "quiescent state where the L2 FW waits until it has an event to process. You can wait in this state forever without an error condition being generated. You only leave this state when the TRM that holds the L1 Spec Trig Fired Mask reports that its FIFO is NOT Empty. Thestate that you go to next depends on whether you are in Normal Mode or ByPass Mode. In Normal Mode you go to State #2 where you a wait for the TRM FIFO that holds Answers from L2 Global to report Not Empty. In ByPass Mode you go to State #2B where you simulate the L2 Processing Delay. This is the first, and currently only, place in the L2 FW control flow where the L2 FW operating mode effects the sequence of operations. 2. In this state you are waiting to have an Answer from the L2 Global Stage. You reach this state only if the L2 FW is in the Normal Operating Mode. You know when the TRM FIFO that buffers Answers from L2 Global is ready to supply an L2 Answer to the L2 FW because this TRM will assert its FIFO Not Empty signal. You wait in this state until either: The L2 Answer TRM FIFO Not Empty signal is asserted in which case you go to State #3 or Until you exceed the State #2 Timeout waiting to get an Answer from L2 Global in which case you go to State #2A. 2A. This state is just like State #2, in that you are waiting to have an Answer from L2 Global. The only difference is that in State #2A the State Engine advertizes, via a TCC readable status register, that State #2 Timed Out waiting for an Answer from L2 Global. The State Engine will stay in t State 2A forever if it does not receive an Answer from L2 Global. When-if it does receive an Answer from L2 Global, which it knows because the L2 Answer TRM FIFO Not Empty will become asserted, then it moves to State #3. 2B. This state is a 80 usec delay to simulate the processing delay of the L2 trigger system. You reach this state only if the L2 FW is in the ByPass Operating Mode. You always exit this state and go to State #3 after the 80 usec delay. 3. When you enter this state you known that the L2 FW Input TRM's are holding all of the data that you need to begin an L2 FW Cycle. To get this data out of the TRM's and into the rest of the L2 FW cards you must assert the TRM Read Enable signal for a period of 1 tick of the Helper Clock. This State persists for just one Helper Clock tick during which the TRM Read Enable signal is asserted. From this State you always go to State #4. 4. In this State we just wait for 3 ticks of the Helper Clock. This delay is to allow the data just pulled from the Input TRM's to settle and flow through the combinatorial logic in the cards of the L2 FW. We always exit this State and go to State #5 after 3 clock ticks. 5. State #5 is where we wait until it is OK to actually distribute the L2 Decision on the Serial Command Link. Two conditions need to be meant before it is OK to begin the L2 Decision distribution sequence. The Master Clock must tell us that two ticks from now the SCL will not be needed to distribute an L1 Accept message. The signal that we use for this is an appropriately delayed and inverted version of the Master Clock Interaction Marker. The L2-BAD cards must NOT be indicating that an L2 Accept will be sent to a Geographic Section that is currently L2 Busy. So as soon as the Master Clock and the L2-BAD cards say that it is OK to begin the process of distributing this L2 Decision via the SCL then we exit this State and enter State #6. Alternatively, if we have waited in State #5 longer than the State 5 Timeout then we enter State #5A. 5A. State 5A is just like State 5 except that the State Engine is advertizing, via a TCC readable status register, that State #5 Timed Out waiting for the appropriate conditions to begin distribution of the L2 Decision. The State Engine will stay in t State 5A forever if it does not find all the the conditions meant that are necessary to begin the distribution of the L2 Decision.. When-if the conditions are meant then the State Engine leaves State #5A and goes to State #6. 6. During State #6 the State Engine asserts the Send L2 Decision signal. This state lasts for just one tick and you always move to State #7 at the end of this tick. Note that the L2 Helper Function generates both the Send L2 Decision signal, which is a direct output of the State Engine, and the Distributing L2 Decision signal which is a Helper Clk latched version of the Send L2 Decision signal. 7. State #7 persists for only one tick and always immediately follows State #6. During State #7 the L3 Control Data Latch Enable signal is asserted. Following this State the State Engine always moves directly to State #8. 8. In this State we just wait for 3 ticks of the Helper Clock. This delay is to allow the L3 Control Data to pass through the FM-Latch cards and settle in the L3 system. As we exit this state we check to see if the Send to L3 Required signal is asserted or not. If Send to L3 Required IS asserted then we go to State #9. If Send to L3 Required is NOT asserted then we go to State #10. 9. State #9 last for just 1 tick of the Helper Clock. During this state the L3 Control Data Strobe to L3 & Increment L3 Transfer Number signal is asserted. We always exit this state after 1 tick and go to State #10. 10. State #10 is used to test whether or not a L2 FW Capture Monitor Data signal should be issued during this L2 FW Cycle. This state last for only 1 tick of the Helper Clock. The State Engine is looking at the L1 Accept Qualifier signal "The L1 FW Captured Monitor Data for this Event" that it receives from the Auxiliary Data TRM to determine whether or not the L2 FW should have a L2 FW Capture Monitor Date signal generated at this time. If L2 FW Capture Monitor Data IS needed for this event then we go to State #11. If L2 FW Capture Monitor Data is NOT needed for this event then we go to State #12. 11. State #11 last for just 1 tick of the Helper Clock. During this state the L2 FW Capture Monitor Data signal is asserted. From State #11 we always go to State #12. 12. We have completed the actual work to distribute this L2 Decision but we do not want to immediately return to the "quiescent" state at the beginning of this this control sequence. Rather we should wait in this State for 20 usec to guarantee that there is ample spacing between the distribution of consecutive L2 Decisions. This becomes especially important when the L2 Answer TRM FIFO is holding a number of L2 Answers which could be distributed in very rapid succission without this 20 usec wait state. At the end of this 20 usec wait we always go to State #1. The following is an ascii drawing of the L2 FW control flow ----------------------------------------------------------- 1. Quiescent, Waiting for L1 Spec Trig Fired Mask FIFO Not Empty Normal Mode ByPass Mode | | V \ ------------ 2. Wait for Answer from L2, i.e. \ Wait for L2 Answer FIFO Not Empty | | Receive Timeout Waiting | L2 Answer for L2 Answer V | | 2B. Simulate L2 | V Processing | Delay, Wait | 2A. Advertize that State #2 80 usec. | Timed Out. Continue waiting | until you get an Answer from L2 | | | | | ____________________/ | | / V V V 3. Assert the L2 FW Input TRM Read Enables | V 4. Wait 3 ticks for L2 FW Input Data from the TRM's to settle. | V 5. Wait for no L2 Busy - L2 Accept conflicts and for a Serial Command Link frame that can be used to distribute this L2 Decision. All conditions meant Timeout Waiting for all the conditions to be meant | | | | V | | 5A. Advertize that State 5 | Timed Out. Continue waiting | until all conditions are meant | | | V V 6. Assert the Send L2 Decision signal for 1 tick (and its Helper Clk latched version, Distributing L2 Decision) | V 7. Assert the L3 Control Data Latch Enable signal for 1 tick | V 8. Wait 3 ticks for the L3 Control Data to settle Send to L3 Required Send to L3 Required IS asserted is NOT asserted | | V \ | 9. Assert the L3 Control Data Strobe & | Increment L3 Transfer Number signal | for 1 tick. | | | _____________/ | / V V 10. Check to see if a L2 FW Capture Monitor Data signal is to be issued for this L2 FW Cycle. Yes, Capture Monitor Data Do Not Issue Capture Mon Data | | V | | 11. Assert, for 1 tick, the L2 FW | Capture Monitor Data signal | | | __________/ | / V V 12. To guarantee a min time between distributing succissive L2 Decision, wait 20 usec before returning to State #1 at the top of this flow control sequence. | V To Step #1 Monitor Data ----------------------- It is much more useful if we can capture L2 FW Monitor Data during L2 FW Cycles that are processing the L2 Decision for L1 Accepts that had L1 FW Monitor Data captured. To do this we need to FIFO the "did this L1 Accept have its Monitor Data captured" bit of information just like we FIFO the list of L1 Specific Triggers Fired. This will be done by the Auxiliary Data TRM by FIFOing the appropiate L1 Accept Qualifier. OK, what Monitor Data gets captured from the L2 FW. First the stuff for which we understand the source: L2 Answer and L1 Spec Trig Fired state information at the TRM outputs States at the outputs of the per Specific Trigger Accept/Reject AONM's per Geographic Section Accept/Reject FOM's Did the current L2 FW Cycle result in an L2 Accept (note that this comes from the FOM listed above) Scalers at the outputs of the FOM's to give count or rate of Accept and Reject per Geo Section. <- Issue of Clock for these scalers Scalers on the L2 Busy line from each Geo Section State data from the output of the FM Latch cards sending data to L3 And now the stuff for which we do not have a very good understand of the source: Count of the number of L2 FW Cycles Number of L2 FW Cycles that have at least one L1 Spec Trig Accepted Number of L2 FW Cycles that have all L1 Spec Trigs that fired Rejected Count of the number of L2 FW Cycles that had an L2 Busy hold. Scaler of the number of 132 nsec tick spent with: a Geo Sect L2 Busy AND an L2 Accept wanting to go to that Geo Sect AND the L2 FW State Engine stuck waiting to distribute the L2 Decision. Up-Down counter of the number of events awaiting their L2 Decision.