Using Multiple Terms (with a Single Tool) Within the L1.5 Cal Trig Original Specification: 15-AUG-1994 Most Recent Revision: 31-AUG-1994 Introduction ------------ It is desirable for the L1.5 Cal Trig to be able to evaluate multiple Terms, using a single Tool with each Term having its own Parameter set. This file describes the release of L15CT software that provides this functionality. This file should be used in addition to the file: TRGL15CTHS:ELECTRON_1X2_3X3_TOOL_SPECIFICATION.TXT to understand the multiple Term operation of the 1x2_EM_vs_3x3_Total Tool. General Description ------------------- It is very important to implement this multiple Term operation in a relatively simple way, one which is straightforward to design and to code, and to test. At the same time, it is important to ensure that the multiple Term operation is rapid at run-time. The following specification of Multiple Term Single Tool L15CT was designed to achieve both of these goals. The basic features of the Multiple Term Single Tool version of L15CT are listed below: - Up to FOUR L15CT Terms may now be used in the L15CT. These 4 Terms: must all use the same Local Tool (which is currently defined to be the 1x2_EM_vs_3x3_Total Tool, i.e. Tool #2), must all use the same Global Tool (again, the 1x2_EM_vs_3x3_Total Tool, i.e. Tool #2), will all examine object candidate seeds from the same EM Reference Set (this is the EM Reference Set for Term #0), but will use a separate Parameter Set for each of the L15CT Terms. - Not all 4 Terms must always be defined in the COOR-to-TCC messages that set up the L1.5 Cal Trig for a given run. - TCC assumes benign default values for all L15CT Terms that are not defined by COOR. - Any L15CT Term that is defined by COOR must be fully defined i.e the following must be specified: The associated EM Reference Set, the Local DSP Tool Number to use (must be 2) and its parameters, the Global DSP Tool Number to use (must be 2) and its parameter, the MFP Ratio for this L15CT Term, and the specification of which L1 Specific Triggers require the evaluation of this L15CT Term. - Term #0 MUST be defined by COOR. - Not all of L15CT Terms need to be defined in the "L1 Specific Trigger vs L15CT Terms" messages that are sent to TCC by COOR. Any L15CT Terms which are not defined in these messages will never cause the L1.5 Cal Trig to "cycle." - Note also that these all 4 L15CT Terms will ALWAYS be evaluated for each Seed that comes from EM Reference Set #0, regardless of the Terms to Evaluate Mask. - Each of the four L15CT Terms will always produce one DeBug Section Type 3 Entry (Derived Constants) per LDSP for Mark and Force Pass events, i.e. a DeBug Section for a Mark and Force Pass event will contain 44 Type 3 Entries. A "normal" event will have no Type 3 Entries in its DeBug Section. - During the processing of an event by the Multiple Term Single Tool version of L15CT, only ONE Reference Set will be obeyed. This is the EM Reference Set #0. Normally EM Reference Set #0 would be associated only with L15CT Term #0. In the Multiple Term Single Tool version of L15CT, EM Reference Set #0 supplies the Seeds for the evaluation of all 4 L15CT Terms. All other Reference Sets are ignored when the Multiple Term Single Tool version of L15CT is processing events. - In the COOR-to-TCC messages, any L15CT Term that is in use must have its associated EM Reference Set defined. If any of Terms #1, #2, #3 are used, it makes sense to specify their associated EM Reference Set to be the same a that for Term #0. - In the DeBug Section Type 2 Entry (Reference Set data) of the Data Block, the Reference Set data for Term #0 ONLY will be present. i.e. there will still be only one Type 2 Entry per LDSP in the DeBug Section for Mark and Force Pass events (and no Type 2 Entries will be generated for "normal" events). - Only ONE scan of Term #0 EM Reference Set will be performed per event processed by the Multiple Term Single Tool version of L15CT. - Only one Tool (again, the currently defined 1x2_EM_vs_3x3_Total Tool, Tool #2), with a separate set of Parameters for each L15CT Term is allowed. Each Parameter set will be mapped to a L15CT Term as describe dabove. In the Multiple Term Single Tool version of L15CT, all Terms are evaluated using Tool #2. - The only change that has been made to Tool #2 was the addition of one longword to each DeBug Section Type 3 element to indicate the EM Et 1x2 Threshold value in ADC Counts (rather than in GeV as it is provided in the Parameter Data). This change is unrelated to the change of L15CT from "single Term" to "multiple Term". Adding this one longword to the DeBug Setion Type 3 elements should have been done when the units of this Parameter were changed from ADC Counts to GeV). Making the change from "single Term" to "multiple Terms" was used as an opportunity to add this one longword. See the specification of the 1x2_EM_vs_3x3_Total Tool for details of this added longword to the DeBug Section Type 3 elements. - No "eta cut" operation was added to the Local Tool #2 at this time. - Only ONE Mark and Force Pass Ratio will be followed. This is the MFP Ratio associated with Term #0. - Any L15CT processing cycle that is MFP will include in its L15CT Data Block DeBug Section MFP data for all 4 L15CT Terms (even if not all 4 L15CT Terms are currently in use). - Even though only the MFP Ratio for Term #0 is followed, all L15CT Terms that are used during a given down load and run of the L15CT must have their MFP Ratio specified. If any of Terms #1, #2, #3 are used, it makes sense to specify their MFP Ratio to be the same as the MFP Ratio for Term #0. - The Terms are all be equivalent (i.e. there is nothing special about any Term). As mentioned above, the only special objects are the EM Reference Set associated with Term #0 and the Mark and Force Pass Ratio associated with Term #0. Implementation -------------- See the 1x2_EM_vs_3x3_Total Tool Specification for a detailed description of the implementation. The flow described below is intended as a very brief reminder, and is not the official driver document. *** in LOCAL DSPs *** - For each Trigger Tower over Ref Set Energy, run a "multi-Term" Tool - calculate 1x2 EM Et Sum - calculate 3x3 Total Et Sum - For each Term (note: always evaluate all 4 Terms) - Compare EM_1x2 to EM_1x2_Threshold_for_This_Term - Compare Ratio to Ratio_Threshold_for_This_Term - If the object passes both comparisons (i.e. EM_1x2 and Ratio are both above threshold), OR if this is an MFP event, then add this object to the Local Object List - End For - End For *** in Global DSPs *** - For each Local Object List - For each Valid Entry in the current Object List - examine the Term # byte and increment the counter of found Objects for that Term - End For - End For - For each Term - Compare the counter for the current Term to its Count Threshold - Set the Term Answer based on the above comparison - End For Data Block ---------- Again, see the 1x2_EM_vs_3x3_Total Tool specification, as well as the L15CT Data Block Format definition, for the detailed description of the Data Block. The following points are only intended as a brief reminder and are not the official driver document. The following changes have been made to the Data Block: - 4 Local Term Parameter Blocks (rather than 1) are defined in the Tool Parameter Section. - 4 Global Term Parameter Blocks (rather than 1) are defined in the Tool Parameter Section. - Each DeBug Section Type 3 Entry receives an additional longword which indicates the value of the 1x2 EM Et Threshold in ADC Counts (this change is unrelated to the upgrade to multiple Terms, as indicated above). This is Derived Constant #5 and is the 8th (and final) longword in each DeBug Section Type 3 Entry. - There are 4 DeBug Section Type 3 Entries for each Local DSP (for a grand total of 44 DeBug Section Type 3 Entries) in each "Mark and Force Pass" Data Block. There are still no DeBug Section Type 3 Entries in a "normal" Data Block. Timing Notes ------------ Recall that the baseline timing was 130 microseconds. In the Local DSPs, each additional Term (above the first) costs approximately 1 microsecond per seed (in a single LDSP). For example, if 2 seeds are found in a single LDSP, and the L1.5 Cal Trig is evaluating 4 Terms (i.e. 3 "additional" Terms), an extra 2*3 = 6 us of dead time is added. In the Global DSP, a fixed overhead of approximately 3 microseconds has been added. In addition, each valid entry in a Local Object List adds approximately 0.5 microseconds. To continue the above example, if both seeds pass 3 of the 4 Terms, there will be 2*3=6 Objects in the Local Object List, and thus an extra 3+0.5*6=6 microseconds of dead time is added. The new timing, with no seeds found, is 136 microseconds. How much work is "throwaway"? ----------------------------- All (or almost all) of the code added to the Local DSPs was "throwaway." But, not a lot of new concepts needed to be developed. The majority of the code to be added is just "more of the same." - The L_Tl_Ini module required additions which ware relatively straightforward. It now caputures, checks, and stores 4 sets of Local Term Parameter Data (rather than 1). Storage space for these new Parameters was added. - The L_Tl_Np% modules required additions which ware also straightforward. It now compares the object data to 4 sets of Parameters (and makes 4 write/no-write decisions) rather than 1. - This required changing the COMPARE_1X2 and COMPARE_RATIO macros so that different Parameters can be used. - This also required changing the ACCEPT_REJECT macro so that it does not return directly to the Scan Routine after rejecting an object - The CONSTANT file needed to be changed to add the new Type 3 Entries to the DeBug Section. Also recall that the length of the Type 3 Entries changed for an unrelated reason. - The DMA Lists and memory allocations "self-adjust" to these changes. - The memory map files were also changed. Very little of the new code added to the Global DSP was throw-away. This was good because quite a bit of this code was new from the ground up. - The G_Scan module required a much smarter Object List Scanner, which searches for non-empty Object Lists and calls the Global Tool to process these non-empty Lists. It also needs to perform Object Count vs. Count Threshold comparisons for all 4 Terms, rather than the hardwired comparisons it had previously used. The structure of the L_Scan module was "lifted" almost intact to become the new G_Scan module. Recall that both of these modules are optimized for speed in the case where no Seeds/Object List Entries are found. - Two G_Tl modules were added, G_Tl_Evn and G_Tl_Odd. They are identical except for details of which registers are used to pass information from the G_Scan module to the G_Tl module. When given a non-empty Object List, they scan the List and increment the per- Term Object Counters. - A G_Tl_Ini module was added, due to the downloadable Count Thresholds. It was also modelled on the L_Tl_Ini module. - The G_Params module was modified to operate with the G_Tl_Ini module. The Global Tool Parameters were previously examined in the G_Params module. - The DMA Lists and memory allocations "self-adjusted" to the changes made in the Local Tool.