Level 1 and Level 2 Trigger Framework Resource programming by COOR ------------------------------------------------------------------ Philippe Laurens, MSU -- April 3, 2002 I. Introduction =============== 1. General ---------- This is the Definition of the Syntax for Communication between COOR and TCC used to Program the Level 1 and Level 2 Trigger Framework resources controlled by TCC. COOR programs the Level 1 and Level 2 Trigger Frameworks by sending command messages to the Trigger Control Computer (TCC) which accepts ITC client connections on TCP port #52160. COOR commands are ASCII messages made of a command ID and a message payload. Other COOR documents (*) describe this protocol in detail, and TCC follows these specifications. This present document describes in more detail the content of the messages (i.e. what appears after the command ID) sent to TCC and how COOR can control the Level 1 and Level 2 Trigger Frameworks resources. (*) http://www-d0.fnal.gov/d0dist/dist/packages/coor/devel/doc/coorover.ps All commands sent to TCC are interpreted in a non-case-sensitive manner, and COOR is encouraged to use a combination of uppercase and lowercase letters that maximizes readability. All Level 2 Framework resources are programmed implicitly along with the Level 1 Framework resources directly targeted by the command messages. No additional message is necessary to program the Level 2 Framework resources. TCC will also control the Level 1 Calorimeter Trigger, and those resources are programmed in a similar manner, as described in a separate document. The syntax for the programming of the L2 Pre-Processors and L2 Global Processor (which is fronted by TCC) will be defined elsewhere. 2. Common Protocol COOR Messages -------------------------------- TCC follows the "Common Protocol" described in the COOR documentation in section 8.2.1. of coorover.ps. TCC processes all commands immediately and in the order they are received. TCC does not use the "batched command" feature allowed by COOR. The following messages are ignored, and no acknowledgement message is returned: - Begin_Block - End_Block - Abort The following messages are acknowledged, but no action is taken at the moment: - Configure The following messages are acknowledged, and the only action taken is to execute an implicit "Increment_LBN" command (cf. section II.4) which will increment the Luminosity Block Number and push a new block of Luminosity Information out to the Luminosity Server: - Begin_Store - End_Store - Pause_Run (this is different from the L1FW_Pause of section II.2.a) - Resume_Run - Stop_Run The following message is acknowledged, and the only action taken is to execute an implicit "SCL_Initialize" command (cf. section II.1.c) which also invokes an implicit "Increment_LBN" command (cf. section II.4): - Start_Run The following common protocol command is implemented and described in full details in section II.1.b: - Init 3. Guidelines ------------- This is a list of guidelines and lessons from Run I which led to some of the syntax choices for Run II: a) Like in Run I keep simple ASCII/human readable format, but improve keywords and formatting (drop fixed length keywords) b) Like in Run I keep one acknowledge per message (or per message group) c) Improve error information sent back in the acknowledgment. And improve feedback from COOR to TAKER, DAQEXP, and logfile to show offending messages and corresponding feedback information. d) Condense the NUMBER of messages with respect to Run I Maybe simply by making the syntax more flexible and allowing setting several/all features of one common object in one message Group the messages: e.g. one message or group/batch per SpTrg Allow setting several/all properties of a SpTrg in one transaction Still need extra message to enable/disable one or a set of SpTrg Still need extra message to change prescale ratios between runs e) Condense the LENGTH of messages by using ranges in syntax (e.g. a range of geographic sections 0:127) More compact Carries same information as exhaustive list Actually emphasizes a contiguous sequence and highlights the holes This was used with great success in Run I L1 CT Reference Sets. f) Minimize the number of SpTrg features to setup but without loosing on functionality and flexibility by clearly defining a default configuration. Define/Implement all message necessary to access all resources, But skip sending messages that match default settings. g) Split "INIT" in 2 pieces (because of Run II use of FPGA technology) Download all FPGA configurations (only after power-up, slow = 5 minutes) Reset to default/idle programming (clean restart, fast = 5 seconds) h) Make use of uppercase-lowercase combination of characters in keywords to help human readability. COOR should use the uppercase-lowercase spelling, but the parser on TCC should be case-NON-sensitive. i) Since TCC receives on one or separate communication channels messages for (at least) the L1 and L2 Frameworks and the L1 Cal Trig (and probably all L2 PreProcessors and L2 Cal Global), try to make the destination subsystem somewhat apparent in the keywords. II) Global System Control ========================= 1) Initialization ----------------- a) Power-Up Configure (i.e. configure all FPGAs) --------------------- The Trigger Frameworks use Field Programmable Gate Arrays (FPGA) to implement their required functionality. These Chips wake up blank and need to be configured. One method to program an FPGA is to use a small serial PROM from which the FPGA automatically loads its programming at power-up. We chose instead to have TCC download the configuration for increased flexibility. We have 17 FPGA's to download per card, and we have about 60 cards to configure. Most cards have the same programming downloaded in parallel into 16 of its 17 FPGA's. This configuration may become part of the TCC booting sequence, or of the Trigger Control Software (TRICS) initialization, but it still makes sense to give COOR the ability to re-configure the hardware on demand. Syntax: Configure_FPGAs This configuration will probably take around 5 minutes, and COOR *MUST* be able to wait that long, at least for this message, even if shorter timeouts are more appropriate for all other messages. If this step hasn't completed, or failed, the L1 framework is most likely not fit to be programmed. The DAQEXP may be able to overlook certain errors after notifying the framework experts. b) Initialize (i.e. load Default Trigger Programming) ------------- Syntax: Full_Initialize or: Init This is the more familiar step where TCC programs all the L1 and L2 FW resources to make the hardware operational. All resources are programmed to their default-non-allocated-state. This default-non-allocated-state puts all resources in a stand-by state where they do not contribute to triggering. A detailed definition of this default-non-allocated-state is described for the Exposure Groups in section III.4 and Specific Triggers in section IV.8. This configuration may take a few seconds, and COOR *MUST* be able to wait that long for this message, even if shorter timeouts are appropriate for other messages. As for the Configure message above, COOR should raise a red flag if TCC returns an error and prevent further download of run configuration before the problem has been cleared or understood. The detail of the actions taken during L1FW_Initialize is described in more details in file trics_ii_initialization.txt in directory http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ c) Initialize Front-Ends via SCL -------------------------------- Syntax: SCL_Initialize This may be a command that COOR will never use directly, but it should still be made accessible to the DAQEXP for special situations. When the Geographic Sections detect a buffer synchronization problem, they raise an error flag on their Serial Command Link (SCL) that will wake up TCC. TCC will (1) pause the run, (2) locate the error and log its occurrence, (3) send Front-End Initialization commands on the SCL to ALL front-ends, (4) wait for all Front-Ends to advertise themselves as ready, and (5) resume the run. There are actually 2 types of errors detected and reported by the front-ends. Front-Ends can report "L1 Errors" which are synchronization problems with the "Buffers awaiting L2 Decision". They can also report detect "L2 Errors" which are synchronization problems with the "Buffers awaiting transfer to L3". TCC logs these 2 types of errors separately, but the same sequence is used to recover from either type of error. TCC will build and maintain a dynamic list of all Geographic Sections explicitly used by COOR at any given time, and listen to errors from (and expect a response from) only those Geographic Sections during an SCL Initialize sequence. cf. section V. The SCL_Initialize command also executes an implicit "Increment_LBN" command (cf. II.4) which which will increment the Luminosity Block Number and push a new block of Luminosity Information out to the Luminosity Server. The detail of the actions taken during SCL_Initialize is described in more details in file scl_initialization_steps.txt in directory http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ 2) Run Control -------------- a) Pause -------- b) Resume --------- Syntax: L1FW_Pause L1FW_Resume Just like in Run I COOR can, with one message, enable or disable ALL the Specific Triggers simultaneously for the same beam crossings. The typical use of these messages happens before and after enabling or disabling a particular subset of Specific Triggers that were programmed earlier. This pause/resume separates successive runs. This mechanism was also used in Run I, via COOR, as a slow speed event flow throttling mechanism when Data Logging was overloaded (I believe). Note: COOR also sends informational "Pause_Run" and "Resume_Run" messages to all systems. TCC ignores those informational messages. 3) Begin-End Run ------------------ a) Begin Run ------------ b) End Run ---------- c) Begin Store -------------- d) End Store ------------ As in Run I, TCC may be requested to take a snapshot of ALL scalers and write them to a file or a database. Writing the file could take a number of seconds, or even minutes depending on how responsive the destination file server was. In Run I COOR would ask for this task to be initiated, then COOR would go about talking to other systems (L3 I believe) and come back to synchronize with TCC. In fact TCC would first capture all the information, which is a nearly instantaneous process, then wait for the host to open and transfer the file. A better approach might be for TCC to acknowledge COOR's message as soon as it has captured the information, and report any file server problem, if any, through the Alarm system. 4) Increment the Luminosity Block Number ------------------------------------ Syntax: Increment_LBN TCC maintains the Luminosity Block Number (LBN) resources. The Luminosity Block Number is a 32 bit number that is recorded with each event being read out. The LBN is later extracted by the Level 3 filter nodes and copied to the event header. The LBN is one of the tags used to index the events in the Event Database. The Luminosity Block Number remains fixed for a certain number of events before it is increment by one count by TCC. TCC shortly pauses data taking while it increments the LBN. Pausing the run allows TCC to cleanly collect a snapshot of all the Luminosity and Live Time related quantities for all Specific Triggers and for each change of LBN. TCC pushes this Luminosity information out to a Luminiosity Server process running on one of the host machines. The Luminosity Block Number is guaranteed to never be reset and always be incrementing over the life of the experiment. This arrangement allows to unequivocally identify any event as to belonging to a particular Luminosity Interval and properly account for Luminosity and Live Time Information. TCC will automatically increment the LBN every minute by default. TCC will also increment the LBN when it receives one of the following messages from COOR: - Begin_Store - End_Store - Start_Run - Stop_Run - Pause_Run - Resume_Run - SCL_Initialize - Increment_LBN III) Specific Trigger Exposure Groups (0:7) ===================================== The concept of Exposure Groups was introduced to allow a flexible, and manageable method of monitoring Specific Trigger Exposure. This is a compromise between allowing more than a single Luminosity related requirement for all 128 Specific Triggers and not having to implement scalers for 128 (Specific Triggers) * 159 (Bunches). cf: www.pa.msu.edu/hep/d0/ftp/l1/framework/measuring_luminosity_online.txt An Exposure Group needs to include all aspects of Specific Trigger programming that might produce dead-time correlated to the distribution of the luminosity among the (up to) 159 Bunches in the machine. We believe there are two main sources of correlated deadtime. Some And-Or Term requirements are in that class (e.g. Single Interaction). The other source is the set of Geographic Sections digitized by a particular Specific Trigger which will thus be disabled by the Front-End Busy signal from these same Geographic Sections. The L1 Framework instruments a maximum of 8 Specific Trigger Exposure Groups. One or several Exposure Groups must be defined first, and the subsequent programming of a particular Specific Trigger will then specify that it belongs to one particular Exposure Group already programmed, as explained in IV.2. 1) List of And-Or Terms (0:255) ----------------------- Syntax: L1FW_Expo_Group 0 And_Or_List 45 -56 255 This message specifies which And-Or Term(s) is (are) part of a particular Exposure Group. The Exposure Group(s) identified by the Number(s) following the "L1FW_Expo_Group" keyword is (are) being programmed to require the list of And-Or Terms following the "And_Or_List" keyword. An And-Or Term can be requested to be asserted or negated (veto). A minus sign identifies a veto term (like in Run I). A plus sign may be present in front of an And-Or Term requested to be asserted, but is not required. Specifying a new list overwrites any previous list, this is NOT an incremental programming. There may not be zero And-Or Terms in the list, and COOR is furthermore required to always include And-Or Term #255 (always high) in all lists. COOR should also include And-Or Term #247 IN VETO which provides a minimum spacing of 2.6 us between successive Level 1 Accepts. This And-Or Term is correlated with the bunch luminosity profile and must thus be included in the Exposure Group programming. This message allows specifying ranges of contiguous And-Or Terms, or contiguous Exposure Groups (using the syntax "n:m"), while this will probably not be very useful for this particular type of message. 2) List of Geographic Sections (0:127) ------------------------------ Syntax: L1FW_Expo_Group 0 Geo_Sect_List 1 5 10:56 58:127 This message specifies which Geographic Section(s) is (are) part of a particular Exposure Group. The Exposure Group(s) identified by the Number(s) following the "L1FW_Expo_Group" keyword is(are) being programmed to require the list of Geographic Sections following the "Geo_Sect_List" keyword. Geographic Sections may NOT be negated. Specifying a new list overwrites any previous list, this is NOT an incremental programming. There may not be zero Geographic Sections in the list, and COOR is furthermore required to always include Geographic Section #127 in all lists. This is required for the proper operation of the L2 Framework. This message allows specifying ranges of Geographic Sections in the form "n:m". Note: COOR may program multiple resources in one message. L1FW_Expo_Group 0 And_Or_List 45 -56 Geo_Sect_List 1:56 58:127 3) Deallocate ------------- Syntax: L1FW_Expo_Group 0 1 2 Deallocate Here COOR can explicitly release a Geographic Section and TCC will return the resources to their Default-NON-allocated-state. cf section III.4. The Geographic Section(s) identified by the Number(s) following the "L1FW_Expo_Group" keyword is(are) being deallocated. Note that we did not define an explicit message to "allocate" a Geographic Section. A Geographic Section is implicitly allocated as soon as COOR sends a message regarding the programming of a new Geographic Section. COOR needs to explicitly deallocate unused Exposure Groups (e.g. when a user exits from his Taker client) so that TCC can stop listening to errors coming from the associated front-ends, as they may be taken offline. 4) Default Programming ---------------------- An Exposure Group that hasn't been addressed by COOR since the last initialization message, or has been explicitly deallocated is guaranteed to be in the following default-non-allocated-state of programming. The default programming of an exposure Group is to: a) require no And-Or Term except for And-Or Term #255 required High resulting in a negated Exposure Group And-Or Fired signal. b) obey none of the 128 Geographic Sections L1 Busy resulting in a negated Exposure Group Front-End Busy signal. c) generate no L1 Accept following the firing of any of the 128 Specific Trigger. d) prevent all 128 Geographic Sections L1 and L2 Error from causing an SCL Initialize sequence. e) prevent all 128 Geographic Sections L2 Busy from stalling the completion of a Level 2 Framework Cycle. IV) Specific Triggers (0:127) ===================== 1) And-Or Terms (0:127) -------------- Syntax: L1FW_Spec_Trig 0 And_Or_List 45 -56 127 89 255 This message specifies which And-Or Term(s) is (are) part of a particular Specific Trigger requirement. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to require the list of And-Or Terms following the "And_Or_List" keyword. An And-Or Term can be requested to be asserted or negated (veto). A minus sign identifies a veto term (like in Run I). A plus sign may be present in front of an And-Or Term requested to be asserted, but is not required. Specifying a new list overwrites any previous list, this is NOT an incremental programming. There may not be zero And-Or Terms in the list, and COOR is furthermore required to always include And-Or Term #255 (always high) in all lists. COOR should also include in veto And-Or Term #247 to provide a minimum spacing of 2.6 us between successive Level 1 Accepts. And-Or Term #247 must be included in all Exposure Group programming, and optionally in the Specific Trigger programming. This message allows specifying ranges of contiguous And-Or Terms (using the syntax "n:m"), but this may not be very useful for this particular type of message. The And-Or Terms specified in the Exposure Group used by a particular Specific Trigger do not have to be repeated in the list of And-Or Terms for this Specific Trigger. Repeating or not these And-Or Terms makes NO difference in the Trigger decisions made by the Specific Trigger. The choice will however have an effect on the And-Or Term Scaler Rates available for monitoring. 2) Exposure Group (0:7) ----------------- Syntax: L1FW_Spec_Trig 0 Expo_Group 1 This message specifies which Specific Trigger Exposure Group this particular Specific Trigger is part of. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to be part of the Exposure Group following the "Expo_Group" Keyword. There must be one and only one Exposure Group defined for a particular Specific Trigger. A Specific Trigger will not be able to send L1 Accepts to any Geographic Section until it has been assigned to one Exposure Group. 3) Sources of Disable --------------------- a) Global Enable/Disable ------------------------ Syntax: L1FW_Spec_Trig 0 1 -2 COOR_Enable This message specifies which Specific Trigger is globally enabled or disabled. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to be globally enabled or globally disabled by COOR. A minus sign flags Specific Trigger(s) that are being disabled, while no minus sign means that the Specific Trigger is being enabled. A plus sign may be present in front of Specific Triggers being enabled but is not required. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m" or "-n:-m"). The default-non-allocated-state of a Specific Trigger is to NOT be globally enabled and COOR does NOT need to issue this message until the Specific Trigger is fully programmed and COOR wants to start a new run including this new Specific Trigger. b) Prescaler ------------ i) Prescaler Modes ------------------ The Run II L1 Trigger Framework offers two possible prescaling modes. The Ratio Mode is the standard way to specify that the Specific Trigger should be enabled only one out of N Beam Crossings, on the average. The Percentage mode is an alternate way to specify that the Specific Trigger should be enabled only N out of every 100 crossings, on the average. Some prescaler ratios can be achieved with prescaler percentages, for example a prescaler percentage of 50 is exaclty equivalent to a prescaler ratio of 2. The percentage mode gives a finer control of prescaling for small prescaler ratios. For example a raw firing rate of 500 Hz can be brought to 400 Hz with a percentage but not with a ratio. For Luminosity measurement purposes, both prescaler modes must be used in a way that guarantees that all 159 ticks in the machine receive a uniform level of exposure. For more details on luminosity measurement, cf. measuring_luminosity_online.txt in http://www.pa.msu.edu/hep/d0/ftp/l1/framework/exposure_groups/ ii) Ratio Mode -------------- Syntax: L1FW_Spec_Trig 0 Prescale_Ratio 1000 Note that "Prescale" is accepted as a synonym for "Prescale_Ratio" for backwards compatibility. This message specifies whether a particular Specific Trigger is being prescaled and identifies the desired prescaler ratio value. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to require the Prescaler Ratio following the "Prescale_Ratio" Keyword. The prescaler Ratio is implemented with a 32 bit counter. The allowed value range is 1 to 2^32 - 1 = 4,294,967,295. A prescaler ratio of 1 will turn off the prescaling feature. The default-non-allocated-state of a Specific Trigger is to NOT be prescaled and COOR does NOT need to issue this message, unless the prescaler feature is desired. COOR should not allow the user to program a prescaler ratio that is not a number prime with 159, i.e. COOR should not program ratios divisible by 3 or by 53. Prescaler ratios multiple of 3 or 53 will result in an un-even exposure of the bunches in the acclerator. iii) Percentage Mode -------------------- Syntax: L1FW_Spec_Trig 0 Prescale_Percent 30 This message specifies whether a particular Specific Trigger is being prescaled and identifies the desired prescaler percentage. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to require the Prescaler Percentage following the "Prescale_Percent" Keyword. The prescaler Percentage is implemented with a 100 bit shift register. The allowed value range is 1 to 100. A prescaler percentage of 100 will turn off the prescaling feature. The default-non-allocated-state of a Specific Trigger is to NOT be prescaled and COOR does NOT need to issue this message, unless the prescaler feature is desired. The prescaler percentage feature intrinsicly guarantees an even exposure of the bunches in the accelerator independently of the percentage value. c) Obey Front-End Busy Disable (a.k.a. Geographic Section L1 Busy) ------------------------------ Syntax: L1FW_Spec_Trig 0 -1 3 Obey_FE_Busy This message specifies which Specific Trigger is programmed to obey its source of Front-End Busy Disable. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to Obey or Ignore its(their) Front-End Busy Signal. The Front-End Busy signal used by a given Specific Trigger is determined by which Exposure Group it belongs to, and is a combination of the L1 Busy Signals from all the Geographic Sections included in that Exposure Group. A minus sign flags a Specific Trigger that is being programmed to ignore its Front-End Busy signal, while no minus sign means that the Specific Trigger is programmed to obey its assigned source of Geographic Section Front-End Busy Disable Signal (i.e. as defined by the Specific Trigger Exposure Group it belongs to). A plus sign may be present in front of Specific Triggers being programmed to obey this source of disable but is not required. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m" or "-n:-m"). The default-non-allocated-state , and normal mode of operation, of a Specific Trigger is to obey its Front-End Busy Signal, and COOR typically does NOT need to issue this message. d) Auto-Disable --------------- i) Auto-Disable Mode -------------------- Syntax: L1FW_Spec_Trig 0 Auto_Disabled This message specifies which Specific Trigger is programmed to use its Auto-Disable feature. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to Use or Ignore its(their) Auto-Disable feature. A minus sign flags a Specific Trigger that is NOT using the Auto-Disable Feature, while no minus sign means that the Specific Trigger is automatically disabled after firing. A plus sign may be present in front of Specific Triggers being programmed to be auto-disabled but is not required. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m" or "-n:-m"). When a Specific Trigger is programmed to use its Auto-Disable feature, it must also be explicitly "re-enabled" as explained below. The default-non-allocated-state, and normal mode of operation, of a Specific Trigger is to NOT use the Auto-Disable feature and COOR typically does NOT need to issue this message. ii) Re-Enable ------------- Syntax: L1FW_Spec_Trig 0 Re_Enable This message specifies which Specific Trigger is being re-enabled. This Specific Trigger must have already been programmed to use its Auto-Disabled feature, cf III.3.d.i. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to be allowed to fire as soon all its(their) other requirements are met. A Specific Trigger that is Re-Enabled will be allowed to fire only once and will be automatically disabled again until the next explicit Re-Enable message from COOR. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m"). The Default state of a Specific Trigger that has just been programmed to use the Auto-Disable feature is to NOT be immediately enabled, and COOR will need to issue this message before the Specific Trigger can have a chance to fire. e) Obey Individual Disable (0:1) -------------------------- f) Obey Global Correlated Disable (0:3) --------------------------------- g) Obey Global De-Correlated Disable (0:3) ------------------------------------ Syntax: L1FW_Spec_Trig 0 Obey_Individual_Disable 0 Syntax: L1FW_Spec_Trig 0 Obey_Correlated_Disable 0 Syntax: L1FW_Spec_Trig 0 Obey_DeCorrelated_Disable 0 These messages specify that a Specific Trigger is programmed to obey various sources of Disable. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to obey or ignore the source of disable identified by the following keyword. A minus sign flags a Specific Trigger that is NOT obeying a particular source of Disable, while no minus sign means that the Specific Trigger is obeying the particular Source of Disable Signal. A plus sign may be present in front of Specific Triggers being programmed to obey this source of disable but is not required. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m" or "-n:-m"). Only one Source of disable can be specified in a message, unless the source keyword is repeated, as in: L1FW_Spec_Trig -0 -1 Obey_Individual_Disable 0 Obey_Individual_Disable 1 The sources of disable in this class which are currently allocated are: - Individual Disable #0 This is allocated to L3 to disable individual Specific Triggers. - Correlated Global Disable #3 This is the "Skip Next Crossing" source of disable, generated and used internally in the L1 Framework and required to prevent the L1 Framework from issuing L1 Accepts on consecutive Beam Crossings. Note that this has now become "Skip next two beam crossings" - De-Correlated Global Disable #3 This is used by TCC to implement the L1FW_Pause/L1FW_Resume messages and enable/disable all Specific Triggers simultaneously for the same crossings. - All other sources are spares. The Default-allocated-state of a Specific Trigger is to obey all sources of disable defined above and ignore all spare sources, and COOR will thus typically NOT need to issue any of these messages. 4) List of L1 Trigger Accept Qualifiers (0:31) --------------------------------------- Each Level 1 Accept Decision is accompanied on each Serial Command Link by a set of 16 L1 Trigger Accept Qualifiers broadcast to all Geographic Sections. There will in fact be two separate sets of 16 L1 Trigger Accept Qualifiers, each set going to a distinct (fixed) subset of the 128 Geographic Sections. COOR may be able to ignore the fact that not all L1 Trigger Accept Qualifiers go to all Geographic Sections. One anticipated usage is to tell some of the L2 Preprocessors whether they need to perform their task, and maybe which of their programmed thresholds or which algorithms they should use. Another known usage of L1 Accept Qualifier is to flag some events as Mark-and-Force-Pass to the Level 2 system (and the Level 3 system may chose to follow along). The Mark-and-Force-Pass Flag will be generated internally in the Level 1 Framework. This is another resource attached to a Specific Trigger that COOR will need to program (with an MFP ratio), but this L2 related resource is not yet described in this document. Another known usage of a L1 Accept Qualifier will be to flag the events that TCC is going to capture for monitoring every 5 seconds so that the same events can be used in all L1 and L2 Trigger systems concerned (i.e. L1 FW, L2 Pre-Processors, L2 Global). Each Specific Trigger can be programmed to assert any subset of the 32 Qualifiers, meaning that the corresponding Qualifiers will be set whenever this particular Trigger fires. When several Specific Triggers Fire the sets of Qualifiers associated with each Specific Trigger that has fired are merged (OR-ed together) to produce the resulting state of the 32 Qualifiers. Syntax: L1FW_Spec_Trig 0 L1_Qualifier 0 2 The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to assert the Level 1 Trigger Accept Qualifiers listed after the "L1_Qualifier" Keyword. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m"). Specific Triggers may NOT appear negated. The Default-allocated-state of a Specific Trigger is to NOT assert any L1 Trigger Accept Qualifier and COOR does NOT need to issue this message unless COOR wants to specify a list of Qualifiers. 5) L2 Unbiased Sample Ratio --------------------------- Syntax: L1FW_Spec_Trig 0 L2_Unbiased_Sample 1000 This message specifies a value for the Level 2 Unbiased Sample Ratio of a Specific Trigger. This feature controls the assertion of the L2 Unbiased Sample L1 Qualifier flag for some fraction of the events. There is only one such L1 Qualifier flag common to all 128 Specific Triggers. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being programmed to require the Level 2 Unbiased Sample Ratio following the "L2_Unbiased_Sample" Keyword. The Level 2 Unbiased Sample Ratio is implemented with a 24 bit Level 2 Unbiased Sample Counter. The allowed value range is 1 to 2^24 = 16,777,216. To program a new Ratio of N, TCC initializes the Counter with a random number between 0 and N-1. The Counter is decremented every time the Specific Trigger fires. The L2 Unbiased Sample L1 Qualifier flag will be set for one event when this Counter reaches the value zero. A Ratio of 1 corresponds to asserting the L2 Unbiased Sample L1 Qualifier flag for every event where this Specific Trigger has fired. The default-non-allocated-state of a Specific Trigger is to have its Level 2 Unbiased Sample Ratio and Counter set to full scale which is nearly equivalent to the feature being disabled. COOR does NOT need to issue this message, unless a specific Level 2 Unbiased Sample Ratio is desired. The Level 2 Unbiased Sample feature cannot be disabled. 6) Force L2 Reject ------------------ Syntax: L1FW_Spec_Trig 0 Force_L2Reject This message specifies that the Specific Trigger will be automatically rejected during the L2 Framework Decision Cycle. As a consequence each of its associated Geographic Sections will automatically receive a L2 Reject (unless another Specific Trigger which requires this same Geographic Section is present in the L2 Specific Trigger Fired Mask). This message may be used when the L2 Framework is either in L2_Global_Ignored Mode or in L2_Global_Obeyed Mode (cf. Chapter V). When the L2 Framework is in L2_Global_Obeyed Mode, the Specific Trigger will still be rejected even if the L2 Global Processor has accepted the Specific Trigger. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m"). Specific Triggers may NOT appear negated. The Default state of a Specific Trigger that has just been programmed is to not be in Force_L2Reject Mode, and COOR only needs to issue this message if this feature is needed. 7) Deallocate ------------- Syntax: L1FW_Spec_Trig 0 1 2 Deallocate Here COOR can explicitly release a Specific Trigger and TCC will return the Trigger to its Default-NON-allocated-state. The Specific Trigger(s) identified by the Number(s) following the "L1FW_Spec_Trig" keyword is(are) being deallocated. This message allows specifying ranges of contiguous Specific Triggers (using the syntax "n:m"). Note that we did not define an explicit message to "allocate" a Specific Trigger. A Specific Trigger is implicitly allocated as soon as COOR sends a message regarding the programming of a new Specific Trigger. 7) syntax extension ------------------- We allow Grouping several Specific Trigger messages into one message, and thus send them in a single network transaction. L1FW_Spec_Trig 0 And_Or_List 45 -56 Expo_Group 1 Prescale 10 L1_Qualifier 2 8) Default Programming ---------------------- A Specific Trigger that hasn't been addressed by COOR since the last initialization message, or has been explicitly deallocated is guaranteed to be in the following default-non-allocated-state of programming. The default programming of a Specific Trigger is to: a) [most importantly] be globally disabled (by COOR) b) require no And-Or Term except for And-Or Term #255 required High resulting in a negated Physics And-Or Fired signal. c) obey its physics And-Or inputs d) ignore all Exposure Groups And-Or inputs e) ignore all Exposure Groups Front-End Busy signals f) ignore the Correlated Sources #0-2 of Global Disable g) obey the Correlated Source #3 of Global Disable. This is the Skip Next Beam Crossing signal internal to the L1 FW h) ignore the De-Correlated Sources #0-2 of Global Disable i) obey the De-Correlated Source #3 of Global Disable. This is used to implement the L1FW_Pause message j) obey the De-Correlated Source #0 of Individual Disable This is the L3 Individual SpTrg Disable Signal k) ignore the De-Correlated Source #1 of individual disable l) disable the Prescaler feature m) disable the Auto-Disable feature n) generate L1 Accepts to none of the 128 Geographic Sections. V) Obey/Ignore L2 Global Processor Decisions ============================================ Syntax: L2_Global_Obeyed L2_Global_Ignored The "L2_Global_Obeyed" message specifies that the L2 Framework must wait for, and obey the L2 Specific Trigger Fired Mask sent by the L2 Global Processor in order to confirm or reject the Specific Triggers present in the L1 Specific Trigger Fired Mask except for those Specific Triggers programmed with the "Force_L2Reject" message which are always automatically rejected during the L2 Framework Decision Cycle, independently of the L2 Specific Trigger Fired Mask. The "L2_Global_Ignored" message specifies that the L2 Framework should wait a fixed amount of time (~100 us) and automatically accept all the Specific Triggers present in the L1 Specific Trigger Fired Mask except for those Specific Triggers programmed with the "Force_L2Reject" message which are automatically rejected during the L2 Framework Decision Cycle. These two modes of operation are mutually exclusive. After an Initialization request from COOR the default Mode is for the L2 Global Processor to be L2_Global_Ignored. COOR is expected to switch this mode of operation only while no Specific Triggers are defined (e.g. right after an Initialization message) and switching mode will likely involve programming the L2 Global Processor (and some L2 Pre-Processors). This will however not be a requirement enforced by TCC and COOR may send either message at any point in time, with or without an accompanying Initialization message. VI) L2 Data Path List of Geographic Sections ============================================ Syntax: L2_Path_Geo_Sect_List 1 5 10:56 58:127 This message specifies the list of Geographic Section(s) required for proper operation of the L2 Trigger and Data Acquisition Path. This list is a unique resource, but may evolve over time as it is the reflection of which L2 Pre-Processors are required in ANY of the runs defined at a given time. ALL Geographic Section specified in the L2 Data Path Geographic Sections List are guaranteed to receive a L1 Accept signal via their Serial Command Links EVERY time a L1 Accept is issued, even if this Geographic Section was not part of the L1 Exposure Group defined for any of the the Specific Triggers in the L1 Specific Trigger Fired Mask. At the later time of the corresponding L2 Decision, a Geographic Section specified in the L2 Data Path Geographic Sections List will receive a L2 Accept ONLY IF at least one of the Specific Triggers that is accepted by the L2 Decision had this Geographic Section explicitely specified in its Exposure Group. All other Geographic Sections (including those which had automatically received a L1 Accept because they were specified in the L2 Data Path Geographic Sections List but which were NOT listed in any of the Exposure Group for the Specific Triggers that were accepted by the L2 Decision) will automatically receive a L2 Reject. TCC takes the responsibility upon receiving this message to go back and update the programming of all previously defined L1 Exposure Groups and L1 Specific Triggers resources accordingly. This also includes the cases where a new L2_Path_Geo_Sect_List is being specified that includes less or more Geographic Sections than were previously defined. Specifying a new list overwrites any previous list; this is NOT incremental programming of resources. The default state of the L2 Data Path Geographic Sections List after an Initialization message corresponds to requiring no Geographic Section. There may not be zero Geographic Sections in the list, and COOR is furthermore required to always include Geographic Section #127 in all lists. A list with only Geographic Section #127 is equivalent to an empty list since Goegraphic Section #127 is by definition also present in all Exposure Group Geographic Section Lists. A non empty list is only useful while in L2_Global_Obeyed Mode but TCC will not enforce this correlation. This feature can thus be used for any other purpose having the same requirements. This message allows specifying one or more ranges of Geographic Sections in the form "n:m". Geographic Sections may NOT appear negated. VII) Geographic Sections Errors =============================== 1) Dynamic List of Geographic Sections to Monitor for L1/L2 Errors ------------------------------------------------------------------ As explained in section II.1.c, the L1 Trigger Framework monitors the Geographic Section Buffer Error lines. TCC will implicitly build a list with the superset of all Geographic Sections specified in all Exposure Groups. TCC will only detect L1/L2 Errors from the Geographic Sections that are currently used in programming. This design decision has an implication which is most important during commissioning. The user will be required to back out of his Taker session and COOR must release the Exposure Group and corresponding Geographic Section before the user can safely turn off a crate he is commissioning. VIII) And-Or Term Errors ====--================== 1) Dynamic List of And-Or Terms to Monitor for FIFO Errors ---------------------------------------------------------- One functionality required of the L1 Framework is to synchronize the information arriving from all L1 subsystems as And-Or Input Terms. Different L1 Subsystems may take different amount of time to reach their decisions and send their And-Or Term information. The L1 Framework And-Or Terms are received in FIFO registers in groups of 16 And-Or Terms accompanied by a Strobe. The Strobe also carries gap signal information and the L1 Framework detects FIFO errors by watching the occurrence of the gap signal received on each group of 16 And-Or Term. cf. receiving_l1_framework_input_terms.txt at http://www.pa.msu.edu/ftp/l1/framework/andor_terms/ TCC will implicitly build a list with the superset of all And-Or Terms specified in all Exposure Groups and all Specific Triggers. TCC will only detect FIFO Errors from the And-Or Terms that are currently used in COOR's programming of the L1 Framework resources. This design decision has an implication which is most important during commissioning. The user will be required to back out of his Taker session and COOR must release the Exposure Group and Specific Trigger before the user can safely turn off a L1 Subsystem he is commissioning. Another implication common to V and VI is that the DAQEXP will need to define a fairly sophisticated "Test Trigger" (or the full Trigger List) before asserting that the Trigger and Acquisition system are working properly.