Document written on September 13, 1997 and last revised on November 28, 1997
The data structures presented here consist of the data that the Level-1 Trigger (Lv1) is going to insert into the PHENIX data stream for every event that is accepted by Lv1. These comprise output from the Local Level-1 algorithms (Ll1) and the Global Level-1 system (Gl1). The former include hit patterns (at the Lv1 granularity) from the six participant subsystems as well as data summaries which are the outputs of the algorithms based on which trigger decisions are made. The latter include accept vectors for granules, partitions and triggers, counter outputs and related information. In addition both Ll1 and Gl1 data incorporate ancillary words to describe granule status (for example fiber optic link status, alignment) and mode of operation (real data taking, calibration, testing etc).
The structures presented here are not in compressed format. They contain, in fact, raw data arranged in a way that they can be directly interpreted by Physics Analysis Modules (PAMs). For example, there are two dimentional arrays representing hit patterns. In real events many - probably most - elements in the arrays will contain zeros. On the other hand, these data are not "utterly raw". In other words they are not in the exact format in which the Lv1 is going to output them in the data stream; they do not include address headers and the hit patterns are organized in arrays whose elements are standard computer words (of the short or long type) with no hit or data summary information being split between consecutive words. Unpacking functions that will map the "utterly raw" data into these structures are, therefore, needed. The Mode and Status words in the structures remain unpacked to save memory space. Each bit in these words have a special significance so that each binary representation carries one and only one message. However, these words are not necessary for data analysis (with the possible exception of the 32 mode bits and the mode enable bit which say if the data are real or made of an injected pattern). The status bits could be looked at only if an error is detected. By default the status words carry 0's when there is no error condition.
A problem that is already present in these structures is that they are not embedded. For example, each calorimeter granule structure contains two sectors but there is no separate definition of sector structures that are, in turn, declared as members of granule structures. This, unfortunate fact stems from the inability of the STIC compiler to handle such situations. (STIC may also have difficulty with two-dimentional arrays but, presumably, this will be fixed soon.) In this regard, these structures are a compromise between the C/C++ way of arranging data (the way objects are organized better) and the practical limitations of STAF. This is also a departure from what already exists in PISORP where, in addition to having structure members, we also have pointer-to-structure members.
As of this moment no strong attention to data alignment within structures has been given. Bit-level masking and other operations that may employ bit fields are not supposed to be done on these structures. The speed of access of member elements has not been thoroughly considered yet. There are no floating point numbers produced by Lv1; all the data (in the structures) are either 2 or 4 byte words.
Lv1 outputs hit patterns (which are actually formed on the FEMs for Lv1) and data summaries per granule. In particular, no hit sums at a sub-granule level are inserted into the data stream. The structures presented here attempt to follow this prescription so that each structure corresponds to a granule (Gl1 is one granule by itself) as much as this is feasible. The arrangement of elements into the arrays is done following the array indices which, thus, are not explicitly included as members. However, in order to make the structures as generic as possible (so that the granules of each subsystem look similar) there are members that define maximum array indices and which are not present in the "utterly raw" data where the indexing is done by the position in the data stream.
It is understood that structure definitions in STAF are equivalent to structure type definitions in C. This implies that a separate declaration must be made for every granule involved and that the name of the structure (type) is not the name of the granule. The latter is defined as a member of the structure. At this point it becomes clear that there must be constructor-type functions that initialize all these structures, give names (or index numbers) to them and specify array sizes. Since such constructors are not available in standard C as class members, they must be provided (and invoked) externally in the form of PAMs.
The indexing system used here is as follows: indices increase with phi starting from phi=0 deg and with z (theta) starting from -|z_max|. in two dimentional arrays the phi index preceeds the z (theta) index. The scheme applies to sectors and arms as well.
The philosophy used in developing data structures for Lv1 is that for every event there is going to be a row in every STAF table whose contents are Lv1 data. Of course, this can be a subject of further discussion.
There are 3 types of structures related to Lv1. The first one, whose name contains the keyword "Gra" pertains to data from one granule of a subdetector. The 6 participant subdetectors may have more than one granule each: Bbc and Tof have 1; Mvd, Crk, and Mui have 2; Emc has 4. These structures contain hit patterns, mode and status words. The second uses the keyword "Sub". These contain summary data, and status words. These 2 types are data inserted into the event data stream and differ from one Lv1-accepted event to another. The last one has the keyword "Par". These are run-fixed parameters including thresholds, cross bars (XBars) and Look-Up Tables (LUTs).
Finally, each table (structure) definition in STAF should be a separate IDL file. Here all these files are presented as one. Corrections and comments are, as always, welcome.
/***********************************************************************
* File: Lv1EmcGra.idl *
* Table: Lv1EmcGra *
* Contents: Lv1 data structure for one Emc granule. There are 4 such *
* granules, 3 for Ems (one in the East Arm, 2 in the West *
* Arm) and 1 for Emg (West Arm). The photon1 and photon2 *
* arrays are hit patterns containg a 1 if the element is ON *
* and a 0 otherwise. Their dimensions are (MaxPhi x MaxZ) *
* 18 x 36 for Ems sectors and 24 x 48 for Emg sectors. *
* The the size of the arrays is determined by the maximum *
* indices in Phi and Z. The number of status words for the *
* granule is controlled by MaxStatus. This is 6 for Ems and *
* 12 for Emg granules. *
* Created: Sep. 8, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: Sep. 9, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Changes: Added MaxStatus as structure member. *
* Sep. 10, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Changes: Renamed Sec1maxz to Sec1MaxZ. *
* Added Mode word. *
***********************************************************************/
struct Lv1EmcGra {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
char Sec1Name[16]; /* Name of first sector. */
char Sec2Name[16]; /* Name of second sector. */
short Sec1Indx; /* Index of the first sector. */
short Sec2Indx; /* Index of the second sector. */
short Sec1MaxPhi; /* Maximum phi index for first sector. */
short Sec2MaxPhi; /* Maximum phi index for second sector. */
short Sec1MaxZ; /* Maximum z index for first sector. */
short Sec2MaxZ; /* Maximum z index for second sector. */
short Sec1Photon1[25][50]; /* Photon1 array for first sector. */
short Sec1Photon2[25][50]; /* Photon2 array for first sector. */
short Sec2Photon1[25][50]; /* Photon1 array for second sector. */
short Sec2Photon2[25][50]; /* Photon2 array for second sector. */
short Mode; /* Granule Mode word. */
short MaxStatus; /* Number of status words for granule. */
short Status[12]; /* Granule Status words (board 1's). */
};
/* End of file "Lv1EmcGra.idl". */
/***********************************************************************
* File: Lv1EmcSub.idl *
* Table: Lv1EmcSub *
* Contents: Lv1 summary data structure for the Emc. There is 1 such *
* structure. The 3 arrays Photon1Sum[4], Photon2Sum[4], and *
* GlobalSum[4] contain the 4 (of 7 possible) sums of the *
* adjacency-corrected Photon1, and Photon2 arrays and the *
* Global (energy) sum selected by XBars. The 7 possible *
* sums are: 4 for each granule, 2 for each arm, and 1 for *
* the whole subdetector. The 4 selected sums are encoded by *
* LUTs into the Photon1SumGl1[4], Photon2SumGl1[4], and *
* GlobalSumGl1[4] arrays that are used for Gl1 decisions. *
* Sums that are not selected are not inserted in the data *
* stream and are lost (they can be reproduced off-line but *
* this does not guarantee that the hardware worked fine). *
* Created: Sep. 9, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1EmcSub {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector. */
short Photon1Sum[4]; /* The 4 Photon1 sums selected by XBar. */
short Photon2Sum[4]; /* The 4 Photon2 sums selected by XBar. */
long GlobalSum[4]; /* The 4 Global sums selected by XBar. */
short Photon1SumGl1[4]; /* The 4 LUT-Encoded Photon1 sums for Gl1. */
short Photon2SumGl1[4]; /* The 4 LUT-Encoded Photon2 sums for Gl1. */
short GlobalSumGl1[4]; /* The 4 LUT-Encoded Global sums for Gl1. */
short CosmicHit; /* If "1", a "cosmic" or "beam" muon hit. */
short Status; /* Granule Status word (board 3). */
};
/* End of file "Lv1EmcSub.idl". */
/***********************************************************************
* File: Lv1EmcPar.idl *
* Table: Lv1EmcPar *
* Contents: Lv1 parameter structure. This is fixed for each run. *
* The index Indx should be the same as for the Emc. *
* The 2 thresholds, Photon1Threshold and Photon2Threshold, *
* reside on the FEMs where the Photon1 and Photon2 arrays *
* are formed. Each XBar is stored as a 2-dimensional array. *
* The first dimension is the input variables and the second *
* is the output. A "1" is inserted at the cross-section *
* element that must be turned ON, meaning that the input *
* variable is directed into the specified output one. Care *
* should be taken so that no 2 or more inputs are directed *
* to the same output (the converse is not necessary), i.,e.,*
* the following matrices must have at most one non-zero *
* entry in each row. *
* *
* Definition of the XBar Photon1SumXbar[7][4]: *
* *
* Gra1 Gra2 Gra3 Gra4 Arm1 Arm2 Det *
* ------------------------------------------- *
* Photon1Sum[0] | | | | | | | | *
* ------------------------------------------- *
* Photon1Sum[1] | | | | | | | | *
* ------------------------------------------- *
* Photon1Sum[2] | | | | | | | | *
* ------------------------------------------- *
* Photon1Sum[3] | | | | | | | | *
* ------------------------------------------- *
* *
* Definition of the XBar Photon2SumXbar[7][4]: *
* *
* Gra1 Gra2 Gra3 Gra4 Arm1 Arm2 Det *
* ------------------------------------------- *
* Photon2Sum[0] | | | | | | | | *
* ------------------------------------------- *
* Photon2Sum[1] | | | | | | | | *
* ------------------------------------------- *
* Photon2Sum[2] | | | | | | | | *
* ------------------------------------------- *
* Photon2Sum[3] | | | | | | | | *
* ------------------------------------------- *
* *
* Definition of the XBar GlobalSumXbar[7][4]: *
* *
* Gra1 Gra2 Gra3 Gra4 Arm1 Arm2 Det *
* ------------------------------------------- *
* Photon2Sum[0] | | | | | | | | *
* ------------------------------------------- *
* Photon2Sum[1] | | | | | | | | *
* ------------------------------------------- *
* Photon2Sum[2] | | | | | | | | *
* ------------------------------------------- *
* Photon2Sum[3] | | | | | | | | *
* ------------------------------------------- *
* *
* Notation: Gra1, Gra2, Gra3, Gra4 are the computed sums *
* for each granule. Arm1 and Arm2 are the sums *
* for each arm. Det is the sum for the whole Emc. *
* the assignment of granule and arm indices must *
* follow the general PHENIX convention and must *
* coinside with the corresponding Lv1EmcGra.Indx. *
* *
* Note: The actual (hardware) XBars also have FEM-unreliable*
* bits as input. These may change on a beam-crossing *
* rate and are programmable via the Scheduler. They *
* are not included here since they are included in *
* Mode words.
* *
* The LUTs are stored as 2-dimensional arrays (each LUT is *
* an array of 1 dimension). The first dimension corresponds *
* to the sum (selected by XBar) to be encoded. The second *
* dimension corresponds to the number bits, n, to which the *
* variable is encoded. Specifically, the number of elements *
* is 2^n - 1. The elements in each LUT are used to define *
* ranges of the input variable. *
* Example: if the LUT Photon1SumLUT[0] contains (2 bits): *
* *
* Photon1SumLUT[0][0] = a[0] (typically a[0] = 0) *
* Photon1SumLUT[0][1] = a[1] *
* Photon1SumLUT[0][2] = a[2] *
* *
* then the following assignment is made: *
* *
* Photon1Sum[0] <= a[0] -> Photon1SumGl1[0] = 0 (b00)*
* a[0] < Photon1Sum[0] <= a[1] -> Photon1SumGl1[0] = 1 (b01)*
* a[1] < Photon1Sum[0] <= a[2] -> Photon1SumGl1[0] = 2 (b10)*
* a[2] < Photon1Sum[0] -> Photon1SumGl1[0] = 3 (b11)*
* *
* The CosmicLUT selects which sector cosmic hit (one, *
* inclusive or exclusive OR of two or more sectors) is sent *
* to Gl1 and the data stream. Here it is stored as an array *
* whose 8 first elements show which sectors contribute and *
* whose 9th element indicates if an OR (set to 0) or XOR *
* (set to 1) is applied. FEM-unreliable bits are also input *
* to the hardware but are not relevant here (note above). *
* The ordering of the sectors follows PHENIX convention: *
* element [0] is the East sector at negative phi and the *
* index increases from there. *
* *
* Created: Sep. 9, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: Sep. 10, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Changes: Added CosmicLUT member. *
***********************************************************************/
struct Lv1EmcPar {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of subdetector (Lv1EmcSub.Indx). */
short Photon1Threshold; /* Threshold for Photon1 (on FEMs). */
short Photon2Threshold; /* Threshold for Photon2 (on FEMs). */
short Photon1SumXBar[7][4]; /* XBar for Photon1Sum selection. */
short Photon2SumXBar[7][4]; /* XBar for Photon2Sum selection. */
short GlobalSumXBar[7][4]; /* XBar for GlobalSum selection. */
short Photon1SumLUT[4][3]; /* 4 LUTs for Photon1 sums (2 bits). */
short Photon2SumLUT[4][3]; /* 4 LUTs for Photon2 sums (2 bits). */
short GlobalSumLUT[4][7]; /* 4 LUTs for Global sums (3 bits). */
short CosmicLUT[9]; /* LUT to select Cosmic hit condition. */
};
/* End of file "Lv1EmcPar.idl". */
/***********************************************************************
* File: Lv1Gl1.idl *
* Table: Lv1Gl1 *
* Contents: Lv1 data structure for Gl1 (this is one granule). These *
* data are produced for every event accepted by Gl1. There *
* is a distinction between granules that participate in Lv1 *
* (Participants, maximum 13 including Gl1) and granules that*
* do not (Spectators, normally 16). The Accept Vectors for *
* Triggers, Granules, and Partitions are promoted to *
* 1-dimentional (short) arrays. *
* The order of granules in the GranuleAccept, *
* GranuleAcceptCounter, ParticipantForcedAccept, *
* SpectatorForcedAccept, ParticipantDisable, and *
* SpectatorDisable vectors follows general PHENIX rules. *
* In particular, the convention for Gl1 vectors is this: *
* *
* (Lv1-Participant group) *
* Gl1 > Bbc > Mvd (South) > *
* Mvd (North) > Crk (East) > Crk (West) > *
* Tof > Emc (East Down) > Emc (East Up) > *
* Emc (West Up) > Emc (West Down) > Mui (South) > *
* Mui (North) > *
* (Lv1-Spectator group) *
* Dc (East) > Dc (West) > Pc1 (East) > *
* Pc1 (West) > Pc2 (East) > Pc2 (West) > *
* Tec (East) > Tec (West) > Pc3 (East) > *
* Pc3 (West) > Mut (South 3) > Mut (South 2) > *
* Mut (South 1) > Mut (North 1) > Mut (North 2) > *
* Mut (North 3) *
* *
* Note that there is a grouping into Participants and *
* Spectators. This is reflected in the Forced Accept and *
* Disable vectors. The Gl1AcceptCounter is treated *
* separately from the GranuleAceptCounter. *
* The assignment of granules into partitions is shown in *
* the Lv1Gl1Par structure. The interpretation of the *
* TriggerAccept vector is associated with the definition of *
* XBars and LUTs shown in Lv1Gl1Par. *
* *
* Created: Sep. 9, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: Sep. 10, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Changes: Added StatusBrd1 and StatusBrd3[8] words. *
***********************************************************************/
struct Lv1Gl1 {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
short TimeStamp[4]; /* Year, Month-Day, Hour-Minute, Second. */
long BeamCrossingCounter; /* Counter of beam crossings. */
short PartitionAccept[32]; /* Partition Accept Vector for event. */
short GranuleAccept[32]; /* Granule Accept Vector for event. */
short TriggerAccept[128]; /* Trigger Accept Vector for event. */
long Gl1AcceptCounter; /* Global Lv1 Accept Counter. */
short GranuleAcceptCounter[31]; /* Granule (non-Gl1) Accept Counters. */
short Participants; /* Number of Participants (default = 13). */
short Spectators; /* Number of Spectators (default = 16). */
short ParticipantForcedAccept[16]; /* Forced accepts for Participants. */
short SpectatorForcedAccept[16]; /* Forced accepts for Spectators. */
short ParticipantDisable[16]; /* Disable Particip. Gran. (default = 13). */
short SpectatorDisable[16]; /* Disable Spectator Gran. (default = 16). */
short Mode; /* Mode word. */
short Gl1LUTHandprint[24]; /* Gl1 LUT Handprint words. */
short StatusBrd3; /* Status word (board 3). */
short StatusBrd1[8]; /* Status words (board 1's). */
};
/* End of file "Lv1Gl1.idl". */
/***********************************************************************
* File: Lv1Gl1Par.idl *
* Table: Lv1Gl1Par *
* Contents: Gl1 run parameters. Most are defined at run set-up. Some *
* (NormalizationScaler) are written at the run end. *
* The PartitionGranule matrix (XBar) shows which granules *
* belong to which partitions using a "1" at the appropriate *
* element. The ordering of the granules follows the *
* convention described in Lv1Gl1.idl. The first dimension *
* of the matrix refers to partitions and the second to *
* granules: *
* *
* Gra0 Gra1 Gra2 ............ Gra30 Gra31 *
* ---------------------------------------------- *
* Par0 | | | | ............ | | | *
* ---------------------------------------------- *
* Par1 | | | | ............ | | | *
* ---------------------------------------------- *
* . . . . *
* . . . . *
* . . . . *
* ---------------------------------------------- *
* Par31 | | | | ............ | | | *
* ---------------------------------------------- *
* *
* According to general convention a granule belongs to at *
* most 1 partition. *
* The PartitionTrigger matrix (Router) shows which triggers *
* belong to which partitions using a "1" at the appropriate *
* element. The first dimension of the matrix refers to *
* partitions and the second to triggers: *
* *
* Tri0 Tri1 Tri2 .................. Tri127 *
* ---------------------------------------------- *
* Par0 | | | | .................. | | *
* ---------------------------------------------- *
* Par1 | | | | .................. | | *
* ---------------------------------------------- *
* . . . . *
* . . . . *
* . . . . *
* ---------------------------------------------- *
* Par31 | | | | .................. | | *
* ---------------------------------------------- *
* *
* According to general convention a trigger belongs to at *
* most 1 partition (but triggers need not be different). *
* The ordering of partitions is the same as in the *
* PartitionAccept vector (Lv1Gl1.idl). *
* The NormalizationScaler and the ScaleDownFactor vectors *
* refer to triggers. The ordering of triggers is as in the *
* PatritionTrigger array. This is the same as in the *
* TriggerAccept vactor (Lv1Gl1.idl). *
* There are 32 selection XBars. Each takes 30 Data Summary *
* (encoded) input from all 12 Local Lv1 participant *
* granules and PPG information for all 32 granules and *
* selects up to 10 of them and directs the output to a LUT. *
* (The number 10 is related to the 20 bits reserved *
* for output. Given the number of reduced data summaries *
* from Local Lv1 to Gl1 there can be at most 8 granules in *
* the output of a XBar.) Each XBar looks like: *
* *
* InDat0 InDat1 ........... InDat62 *
* ------------------------------------- *
* OutDat0 | | | | | *
* ------------------------------------- *
* OutDat1 | | | | | *
* ------------------------------------- *
* . . . *
* . . . *
* . . . *
* ------------------------------------- *
* OutDat10 | | | | | *
* ------------------------------------- *
* *
* The ordering of the input words is done as follows: *
* *
* (Participant encoded words): *
* Bbc (2 w) [0,1] > Mvd (3 w) [2-4] > Crk (3 w) [5-7] > *
* Tof (1 w) [8] > Emc (13 w) [9-21] > Mui (8 w) [22-29]> *
* (Participant PPG words) *
* Gl1 [30]> Bbc [31] > Mvd (South)[32] >*
* Mvd (North) [33]> Crk (East) [34] > Crk (West) [35] >*
* Tof [36]> Emc (East Down)[37]> Emc (East Up)[38]>*
* Emc (West Up)[39]> Emc (West Down)[40]> Mui (South)[41] >*
* Mui (North) [42]> *
* (Spectator PPG words) *
* Dc (East) [43] > Dc (West) [44] > Pc1 (East) [45] >*
* Pc1 (West) [46] > Pc2 (East) [47] > Pc2 (West) [48] >*
* Tec (East) [49] > Tec (West) [50] > Pc3 (East) [51] >*
* Pc3 (West) [52] > Mut (South 3)[53] > Mut (South 2)[54]>*
* Mut (South 1)[55] > Mut (North 1)[56] > Mut (North 2)[57]>*
* Mut (North 3)[58] *
* *
* The numbers in "[]" indicate the unique coding of these *
* words that is also used in the G1lXBarLUTCode array. *
* The words pertaining to each participant subdetector are *
* determined by the encoding LUTs in this subdetector's *
* run parameter structure. The internal order is also *
* defined there. *
* The trigger request is done by means of 32 LUTs. Each has *
* 20 input bits, i.e., a maximum of 10 2-bit encoded words *
* and 4 output bits, i.e., 4 possible trigger requests. *
* Due to the overwhelming number of possibilites of input *
* conditions (2^20 = 1,048,576 options per LUT !) these *
* LUTs are stored as two arrays: Gl1LUT[32][10][4] and *
* Gl1LUTWord[32][10]. The first dimension in either array *
* corresponds to the LUT; the second to the input encoded *
* data summary words; the third dimension in Gl1LUT is the *
* trigger request. The array Gl1LUTWord contains the actual *
* value of each of the 10 input words per LUT. This value *
* is used in the trigger condition, e.g., 2 rings in Crk. *
* The first and second dimensions of the two arrays are *
* indexed in the same way and as the third dimension of *
* Gl1XBar. Example: the Gl1LUT[1] array looks like: *
* *
* Word0 Word1 ............ Word9 *
* ------------------------------------- *
* TriReq0 | | | | | *
* ------------------------------------- *
* TriReq1 | | | | | *
* ------------------------------------- *
* TriReq2 | | | | | *
* ------------------------------------- *
* TriReq3 | | | | | *
* ------------------------------------- *
* *
* The meaning of the 10 input words per LUT (or output *
* per XBar is given in the array Gl1XbarLUTCode[32][10]. *
* *
* Created: Sep. 10, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1Gl1Par {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule (Lv1Gl1.Indx). */
short PartitionGranule[32][32]; /* Granule to Partition assignment. */
short PartitionTrigger[32][128]; /* Trigger to Partition assignment. */
short TriggerMask[128]; /* Trigger Mask (From VME, startup). */
long NormalizationScaler[128]; /* Norm. Scalers (To VME, end of run). */
short ScaleDownFactor[128]; /* Trigger Scaledown (From VME, startup).*/
short Gl1XBar[32][62][10]; /* The 32 selection XBars. */
short Gl1LUT[32][10][4]; /* The 32 trigger-request LUTs. */
short Gl1LUTWord[32][10]; /* Content of the 10 LUT input words. */
short Gl1XBarLUTCode[32][10]; /* Code of the 10 LUT/XBar in/out words. */
};
/* End of file "Lv1Gl1Par.idl". */
/***********************************************************************
* File: Lv1CrkGra.idl *
* Table: Lv1CrkGra *
* Contents: Lv1 data structure for one Crk granule. There are 2 such *
* granules, 1 in the East Arm and 1 in the West Arm. The *
* RingArray consists of tile-over-threshold elements. These *
* are "1" if the tile is over threshold and "0" otherwise. *
* The RingArray is formed on the FEMs. Its first dimension *
* (Phi) has a maximum index of MaxPhi and its second (Z) of *
* MaxZ. The ordering follows general PHENIX convention. *
* Created: Sep. 11, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1CrkGra {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
short MaxPhi; /* Maximum Phi index (default = 16). */
short MaxZ; /* Maximum Z index (default = 8). */
short RingArray[16][10]; /* Array of ring hit pattern. */
short Mode; /* Granule Mode word. */
short Status[4]; /* Granule Status words (board 1's). */
};
/* End of file "Lv1CrkGra.idl". */
/***********************************************************************
* File: Lv1CrkSub.idl *
* Table: Lv1CrkSub *
* Contents: Lv1 data structure for the Crk subdetector. There is 1 *
* such structure. Note that there are no XBars in the Crk *
* Lv1 algorithm. All 3 produced ring sums are inserted in *
* encoding LUTs. *
* Created: Sep. 11, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1CrkSub {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector. */
short EastRingSum; /* Ring sum for the East granule. */
short WestRingSum; /* Ring sum for the West granule. */
short TotalRingSum; /* Ring sum for the whole subdetector. */
short EastRingSumGl1; /* Encoded East ring sum (for Gl1). */
short WestRingSumGl1; /* Encoded West ring sum (for Gl1). */
short TotalRingSumGl1; /* Encoded total ring sum (for Gl1). */
short Status; /* Granule Status word (board 2). */
};
/* End of file "Lv1CrkSub.idl". */
/***********************************************************************
* File: Lv1CrkPar.idl *
* Table: Lv1CrkPar *
* Contents: Lv1 run-fixed data structure for the Crk subdetector. *
* There is 1 such structure. Note that there are no XBars *
* in the Crk Lv1 algorithm. All 3 produced ring sums are *
* inserted in encoding LUTs. *
* Each LUT is an array of 1 dimension that corresponds *
* to the number of bits, n, to which the variable *
* is encoded. Specifically, the number of elements *
* is 2^n - 1. The elements in each LUT are used to define *
* ranges of the input variable. *
* Example: if the LUT EastRingSumLUT contains (2 bits) *
* *
* EastRingSumLUT[0] = a[0] (typically a[0] = 0) *
* EastRingSumLUT[1] = a[1] *
* EastRingSumLUT[2] = a[2] *
* *
* then the following assignment is made: *
* *
* EastRingSum <= a[0] -> EastRingSumGl1 = 0 (b00) *
* a[0] < EastRingSum <= a[1] -> EastRingSumGl1 = 1 (b01) *
* a[1] < EastRingSum <= a[2] -> EastRingSumGl1 = 2 (b10) *
* a[2] < EastRingSum -> EastRingSumGl1 = 3 (b11) *
* *
* FEM-unreliable bits that are input in the LUTs may change *
* from one beam crossing to another, as programmed by the *
* Scheduler and included in the Mode words. *
* *
* Created: Sep. 11, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1CrkPar {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector (Lv1CrkSub.Indx). */
short Threshold; /* Threshold for RingArray (on FEMs). */
short EastRingSumLUT[3]; /* LUT for EastRingSum (2 bits). */
short WestRingSumLUT[3]; /* LUT for WestRingSum (2 bits). */
short TotalRingSumLUT[3]; /* LUT for TotalRingSum (2 bits). */
};
/* End of file "Lv1CrkPar.idl". */
/***********************************************************************
* File: Lv1TofGra.idl *
* Table: Lv1TofGra *
* Contents: Lv1 data structure for the Tof granule. There is 1 such *
* granule only (East Arm). The TofArray has a "1" in each *
* element that has a valid hit and a "0" everywhere else. *
* Its maximum size is controlled by MaxPhi (default = 1024).*
* Created: Sep. 11, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1TofGra {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
short MaxPhi; /* Maximum Phi index (default = 1024). */
short TofArray[1024]; /* Array of Tof hit pattern. */
short Mode; /* Granule Mode word. */
short Status[2]; /* Granule Status words (board 1's). */
};
/* End of file "Lv1TofGra.idl". */
/***********************************************************************
* File: Lv1TofSub.idl *
* Table: Lv1TofSub *
* Contents: Lv1 data structure for the Tof subdetector. There is 1 *
* such structure. Note that there are no XBars in the Tof *
* Lv1 algorithm. The produced Tof sum is inserted in the *
* encoding LUT. *
* Created: Sep. 11, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1TofSub {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector. */
short TofSum; /* Sum of the TofArray elements. */
short TofSumGl1; /* Encoded TofArray sum (for Gl1). */
short Status; /* Granule Status word (board 2). */
};
/* End of file "Lv1TofSub.idl". */
/***********************************************************************
* File: Lv1TofPar.idl *
* Table: Lv1TofPar *
* Contents: Lv1 run-fixed data structure for the Tof subdetector. *
* There is 1 such structure. Note that there are no XBars *
* in the Tof Lv1 algorithm. The produced Tof sum is *
* inserted in the encoding LUT. *
* The LUT is an array of 1 dimension that corresponds *
* to the number of bits, n, to which the variable *
* is encoded. Specifically, the number of elements *
* is 2^n - 1. The elements in the LUT are used to define *
* ranges of the input variable. *
* If the LUT TofSumLUT contains (2 bits): *
* *
* TofSumLUT[0] = a[0] (typically a[0] = 0) *
* TofSumLUT[1] = a[1] *
* TofSumLUT[2] = a[2] *
* *
* then the following assignment is made: *
* *
* TofSum <= a[0] -> TofSumGl1 = 0 (b00) *
* a[0] < TofSum <= a[1] -> TofSumGl1 = 1 (b01) *
* a[1] < TofSum <= a[2] -> TofSumGl1 = 2 (b10) *
* a[2] < TofSum -> TofSumGl1 = 3 (b11) *
* *
* FEM-unreliable bits that are input in the LUTs may change *
* from one beam crossing to another, as programmed by the *
* Scheduler and are included in the Mode words. *
* *
* Created: Sep. 11, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1TofPar {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector (Lv1TofSub.Indx). */
short TofSumLUT[3]; /* LUT for TofSum (2 bits). */
};
/* End of file "Lv1TofPar.idl". */
/***********************************************************************
* File: Lv1BbcGra.idl *
* Table: Lv1BbcGra *
* Contents: Lv1 data structure for the Bbc granule. There is 1 such *
* granule only (North and South counters together). The *
* maximum index in the NorthTimeHist and SouthTimeHist *
* arrays is MaxTimeIndx. Its default value is 128. This is *
* is not part of the time gate run-fixed parameters. *
* The Mode word contains (among others) the FEM-unreliable *
* which is, in fact, used by the Lv1 Bbc algorithm to *
* determine the ValidityFlag in Lv1BbcSub. *
* Created: Sep. 12, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1BbcGra {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
short MaxTimeIndx; /* Maximum time index in the histogram array. */
short NorthTimeHist[128]; /* Histogram of North arrival times. */
short SouthTimeHist[128]; /* Histogram of South arrival times. */
short Mode; /* Granule Mode word. */
short Status[4]; /* Granule Status words (board 1's). */
};
/* End of file "Lv1BbcGra.idl". */
/***********************************************************************
* File: Lv1BbcSub.idl *
* Table: Lv1BbcSub *
* Contents: Lv1 data structure for the Bbc subdetector. There is 1 *
* such structure. Note that there are no XBars or LUTs in *
* the Bbc Lv1 algorithm. (There is a LUT that *
* is used to reduce the 10-bit ABC signals from each PMT *
* to the most significant 7 bits, but this is not likely to *
* change and is not included in the Lv1BbcPar structure.) *
* Created: Sep. 12, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1BbcSub {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector. */
short NorthPeakCount; /* Counts at the peak of NorthTimeHist. */
short NorthTime; /* Time slot of the NorthTimeHist peak. */
short NorthHit; /* North counter valid hit flag. */
short SouthPeakCount; /* Counts at the peak of SouthTimeHist. */
short SouthTime; /* Time slot of the SouthTimeHist peak. */
short SouthHit; /* South counter valid hit flag. */
short AverageTime; /* Event time (average of North and South). */
short Vertex; /* Vertex position (North-South difference). */
short EventFlag; /* ON if at least one counter has a valid hit. */
short ValidityFlag; /* ON if both counters have a valid hit. */
short Status; /* Granule Status word (board 2). */
};
/* End of file "Lv1BbcSub.idl". */
/***********************************************************************
* File: Lv1BbcPar.idl *
* Table: Lv1BbcPar *
* Contents: Lv1 run-fixed data structure for the Bbc subdetector. *
* There is 1 such structure. Note that there are no XBars *
* or LUTs in the Bbc Lv1 algorithm. (There is a LUT that *
* is used to reduce the 10-bit ABC signals from each PMT *
* to the most significant 7 bits, but this is not likely to *
* change and is not included here.) *
* Created: Sep. 12, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1BbcPar {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector (Lv1BbcSub.Indx). */
short MaxTime; /* Maximum time index allowed (remove overflow). */
short MinTime; /* Minimum time index allowed (remove 0 times). */
short NorthMinCount; /* Minimum NorthPeakCount allowed. */
short SouthMinCount; /* Minimum SouthPeakCount allowed. */
short NorthMaxTime; /* Upper bound of NorthTime allowed by gate. */
short NorthMinTime; /* Lower bound of NorthTime allowed by gate. */
short SouthMaxTime /* Upper bound of SouthTime allowed by gate. */
short SouthMinTime; /* Lower bound of SouthTime allowed by gate. */
short MaxVertex; /* Upper bound of Vertex allowed by gate. */
short MinVertex; /* Lower bound of Vertex allowed by gate. */
};
/* End of file "Lv1BbcPar.idl". */
/***********************************************************************
* File: Lv1MvdGra.idl *
* Table: Lv1MvdGra *
* Contents: Lv1 data structure for the one Mvdgranule. There are 2 *
* such granules one for the North and one for the South. *
* WARNING!!! IN HARDWARE THE 2 GRANULES MAYBE PADS AND *
* STRIPS RATHER THAN NORTH AND SOUTH. DEFINING NORTH AND *
* SOUTH GRANULES MAKES THEIR RESPECTIVE STRUCTURES *
* IDENTICAL. IF HARDWARE GRANULES ARE DEFINED AS PADS AND *
* STRIPS THEN THE UNPACKER CAN EASILY PUT THE DATA IN THE *
* RIGHT STRUCTURE. THE LV1 DATA CAN BETTER BE ARRANGED AS *
* AS NORTH AND SOUTH STRUCTURES. THIS CAN BE SEEN IN THE *
* DEFINITION OF MODE BITS. *
* The input to the Mvd algorithm consists of sums over each *
* wafer of silicon strips or pads. By default there are *
* 12 pad wafers and 36 strip wafers per granule, North or *
* South). These are represented by the PadWaferRaw and *
* StripWaferRaw arrays. Their size is controlled by *
* PadWaferNumber and StripWaferNumber, respectively. *
* The wafer sums after being corrected for vertex position *
* by LUTs are stored in the arrays PadWaferCor and *
* StripWaferCor (of the same size), respectively. *
* Created: Sep. 12, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1MvdGra {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
short PadWaferNumber; /* Number of Pad input sums (default = 12). */
short StripWaferNumber; /* Number of Strip input sums (default = 36). */
short PadWaferRaw[12]; /* Pad input sums (uncorrected). */
short StripWaferRaw[36]; /* Strip input sums (uncorrected). */
short PadWaferCor[12]; /* Pad input sums (LUT-corrected). */
short StripWaferCor[36]; /* Strip input sums (LUT-corrrected). */
short Mode; /* Granule Mode word. */
short Status[2]; /* Granule Status words (board 1's). */
};
/* End of file "Lv1MvdGra.idl". */
/***********************************************************************
* File: Lv1MvdSub.idl *
* Table: Lv1MvdSub *
* Contents: Lv1 data structure for the Mvd subdetector. There is 1 *
* such structure. The Mvd algorithm is the only one that *
* uses input from another subsystem, the Bbc. The Bbc vertex*
* position estimate and validity flag (see Lv1BbcSub.idl) *
* are used. There is a HistoryMarquee array that records *
* the Mvd TotalSum for the duration of 21 beam crossings. *
* There are 9 possible sums produced by the Mvd Lv1: *
* NorthPadSum, NorthStripSum, SouthPadSum, SouthStripSum, *
* (these are sums of the corresponding array elements in *
* each of the two Lv1MvdGra structures), PadSum, StripSum, *
* (these are total sums of pads or strips of both granules),*
* NorthSum, SouthSum (these are sums for pad nad strips per *
* granule), and TotalSum (sum of everything). Three sums *
* selected by the XBar (MvdSumXBar), i.e., MvdSum[3]. *
* The 3 sums are encoded by LUTs into the MvdSumGl1[3] *
* array that is used for Gl1 decisions. *
* Sums that are not selected are not inserted in the data *
* stream and are lost (they can be reproduced off-line but *
* this does not guarantee that the hardware worked fine). *
* Created: Sep. 12, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1MvdSub {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector. */
short MvdSum[3]; /* The 3 Mvd sums selected by XBar. */
short MvdSumGl1[3]; /* The 3 LUT-encoded Mvd sums for Gl1. */
short HistoryMarquee[21]; /* A 21-beam-crossing array of Mvd TotalSum's. */
short Vertex; /* From Lv1BbcSub.Vertex. */
short ValidityFlag; /* From Lv1BbcSub.ValidityFlag. */
short Status; /* Granule Status word (board 2). */
};
/* End of file "Lv1MvdSub.idl". */
/***********************************************************************
* File: Lv1MvdPar.idl *
* Table: Lv1MvdPar *
* Contents: Lv1 run-fixed data structure for the Mvd subdetector. *
* There is 1 such structure. A XBar is used to select 3 *
* of the 9 possible sums formed to encode and send to Gl1 *
* and the data stream. The XBar is stored as a 2-dimensional*
* array. The first dimension is the input variables and the *
* second is the output. A "1" is inserted at the *
* cross-section element that must be turned ON, meaning *
* that the input variable is directed into the specified *
* output one. Care should be taken so that no 2 or more *
* inputs are directed to the same output (the converse is *
* not necessary), i.,e., the following matrix must have at *
* most one non-zero entry in each row. *
* *
* Definition of the XBar MvdSumXbar[9][3]: *
* *
* PadS PadN StrS StrN Pad Str Sou Nor Tot *
* ---------------------------------------------- *
* MvdSum[0] | | | | | | | | | | *
* ---------------------------------------------- *
* MvdSum[1] | | | | | | | | | | *
* ---------------------------------------------- *
* MvdSum[2] | | | | | | | | | | *
* ---------------------------------------------- *
* *
* All 3 selected sums are inserted in encoding LUTs. *
* Each LUT is an array of 1 dimension that corresponds *
* to the number of bits, n, to which the variable *
* is encoded. Specifically, the number of elements *
* is 2^n - 1. The elements in each LUT are used to define *
* ranges of the input variable. The 3 LUTs are arranged as *
* a 2-dimensional array, MvdSumLUT[3][7]. *
* Example: if the LUT MvdSumLUT[0] contains (3 bits) *
* *
* MvdSumLUT[0][0] = a[0] (typically a[0] = 0) *
* MvdSumLUT[0][1] = a[1] *
* MvdSumLUT[0][2] = a[2] *
* MvdSumLUT[0][3] = a[3] *
* MvdSumLUT[0][4] = a[4] *
* MvdSumLUT[0][5] = a[5] *
* MvdSumLUT[0][6] = a[6] *
* *
* then the following assignment is made: *
* *
* MvdSum[0] <= a[0] -> MvdSumGl1[0] = 0 (b000) *
* a[0] < MvdSum[0] <= a[1] -> MvdSumGl1[0] = 1 (b001) *
* a[1] < MvdSum[0] <= a[2] -> MvdSumGl1[0] = 2 (b010) *
* a[2] < MvdSum[0] <= a[3] -> MvdSumGl1[0] = 3 (b011) *
* a[3] < MvdSum[0] <= a[4] -> MvdSumGl1[0] = 4 (b100) *
* a[4] < MvdSum[0] <= a[5] -> MvdSumGl1[0] = 5 (b101) *
* a[5] < MvdSum[0] <= a[6] -> MvdSumGl1[0] = 6 (b110) *
* a[6] < MvdSum[0] -> MvdSumGl1[0] = 7 (b111) *
* *
* FEM-unreliable bits that are input in the LUTs may change *
* from one beam crossing to another, as programmed by the *
* Scheduler and are included in the Mode words. *
* *
* A special feature of the Lv1 Mvd algortithm is that it *
* makes provisions for a possible correction of the pad and *
* strip sums for different vertex locations. This correction*
* is accomplished by means of LUTs. There are 36 such LUTs *
* for strips (one per wafer) and 12 for pads for each of *
* the 2 granules for a total of 96 LUTs. Each is stored *
* as a 2-dimensianl array (differently from the encoding *
* LUTs). In turn there are 4 arrays of LUTs one for the *
* pads and one for the strips of each granule: *
* NorthPadLUT[12][128][128], SouthPadLUT[12][128][128], *
* NorthStripLUT[36][128][128], SouthStripLUT[36][128][128]. *
* The second dimension each each array is indexed by the *
* value of the vertex (coming from Lv1-Bbc) and the third *
* is indexed by the actual value of the sum. Its element *
* then contains the value of the output (corrected) sum. *
* Note that if the ValididityFlag is 0 then vertex at z=0 *
* is selected. The second and third indices increase with *
* the values of the vertex and the sums, respectively. The *
* first index follows general PHENIX convention. *
* *
* Created: Sep. 12, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1MvdPar {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector (Lv1MvdSub.Indx). */
short MvdSumXbar[9][3]; /* Selection XBar for the 3 Mvd sums. */
short MvdSumLUT[3][7]; /* Encoding LUTs for the 3 selected sums. */
short NorthPadLUT[12][128][128]; /* 12 vertex-correction LUTs (N-Pad). */
short SouthPadLUT[12][128][128]; /* 12 vertex-correction LUTs (S-Pad). */
short NorthStripLUT[36][128][128]; /* 36 vertex-correction LUTs (N-Str). */
short SouthStripLUT[36][128][128]; /* 36 vertex-correction LUTs (S-Str). */
};
/* End of file "Lv1MvdPar.idl". */
/***********************************************************************
* File: Lv1MuiGra.idl *
* Table: Lv1MuiGra *
* Contents: Lv1 data structure for one Mui granule. There are 2 such *
* granules (North, South). *
* The hit pattern consists of the XRoad and the YRoad arrays*
* whose dimensions are determined by MaxXRoad and MaxYRoad, *
* respectively. The sum array indices are for "shallow" (0) *
* and for "deep" (1). *
* Created: Sep. 13, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: Nov. 28, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Changes: Added dimension to sums. *
***********************************************************************/
struct Lv1MuiGra {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the granule. */
short MaxXRoad; /* Size of XRoad array (default = 326). */
short MaxYRoad; /* Size of YRoad array (default = 308). */
short XRoad[326]; /* Array of X roads. */
short YRoad[308]; /* Array of Y roads. */
short Mode; /* Granule Mode word. */
short Status[8]; /* Granule Status words (board 1's). */
};
/* End of file "Lv1MuiGra.idl". */
/***********************************************************************
* File: Lv1MuiSub.idl *
* Table: Lv1MuiSub *
* Contents: Lv1 data structure for the Mui subdetector. There is 1 *
* such structure. Note that there are no XBars in the Tof *
* Lv1 algorithm. The produced Mui sums are inserted in the *
* encoding LUTs. There are 2 sums per granule: one for the *
* X-roads and one for the Y-roads. *
* Created: Sep. 13, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: *
***********************************************************************/
struct Lv1MuiSub {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector. */
short NorthXSum[2]; /* North X-road sum. */
short NorthYSum[2]; /* North Y-road sum. */
short SouthXSum[2]; /* South X-road sum. */
short SouthYSum[2]; /* South y-road sum. */
short NorthXSumGl1[2]; /* North X-road encoded sum (for Gl1). */
short NorthYSumGl1[2]; /* North Y-road encoded sum (for Gl1). */
short SouthXSumGl1[2]; /* South X-road encoded sum (for Gl1). */
short SouthYSumGl1[2]; /* South Y-road encoded sum (for Gl1). */
short Status; /* Granule Status word (board 2's). */
};
/* End of file "Lv1MuiSub.idl". */
/***********************************************************************
* File: Lv1MuiPar.idl *
* Table: Lv1MuiPar *
* Contents: Lv1 run-fixed data structure for the Mui subdetector. *
* There is 1 such structure. Note that there are no XBars *
* in the Mui Lv1 algorithm. The produced Tof sum is *
* inserted in the encoding LUT. *
* The LUT is an array of 1 dimension that corresponds *
* to the number of bits, n, to which the variable *
* is encoded. Specifically, the number of elements *
* is 2^n - 1. The elements in the LUT are used to define *
* ranges of the input variable. *
* Example: If the LUT NorthXRoadSumLUT contains (2 bits): *
* *
* NorthXRoadSumLUT[0] = a[0] (typically a[0] = 0) *
* NorthXRoadSumLUT[1] = a[1] *
* NorthXRoadSumLUT[2] = a[2] *
* *
* then the following assignment is made: *
* *
* NorthXRoadSum <= a[0] -> NorthXRoadSumGl1 = 0 (b00)*
* a[0] < NorthXRoadSum <= a[1] -> NorthXRoadSumGl1 = 1 (b01)*
* a[1] < NorthXRoadSum <= a[2] -> NorthXRoadSumGl1 = 2 (b10)*
* a[2] < NorthXRoadSum -> NorthXRoadSumGl1 = 3 (b11)*
* *
* For each element in the hit sum arrays there is a LUT. *
* This is indicated by the first index in the LUT arrays. *
* "Shallow" corresponds to 0 and "deep" to 1. *
* FEM-unreliable bits that are input in the LUTs may change *
* from one beam crossing to another, as programmed by the *
* Scheduler and are included in the Mode words. *
* *
* Created: Sep. 13, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Revised: Nov. 28, 97 By: A. Petridis, ISU (petridis@iastate.edu) *
* Changes: Added dimension to LUTs
***********************************************************************/
struct Lv1MuiPar {
char Name[16]; /* Name of the structure. */
short Indx; /* Index of the subdetector (Lv1MuiSub.Indx). */
short NorthXRoadSumLUT[2][3]; /* LUT to encode NorthXRoadSum to 2 bits. */
short NorthYRoadSumLUT[2][3]; /* LUT to encode NorthYRoadSum to 2 bits. */
short SouthXRoadSumLUT[2][3]; /* LUT to encode SouthXRoadSum to 2 bits. */
short SouthYRoadSumLUT[2][3]; /* LUT to encode SouthYRoadSum to 2 bits. */
};
/* End of file "Lv1MuiPar.idl". */
to the Level-1 Publications Page