TMB-to-MPC Trigger Data Format Changes related to GEM

1. TMB-to-MPC Trigger Data Format Changes related to GEM Vadim Khotilovich, Texas A&M University US CMS EMU Workshop2013-10-01

2. Intro • When we would start taking advantage of GEM during trigger stubs reconstruction, we would have to re-define the LCT raw data format to store some GEM-related information • This data is transferred from TMB to MPC and is further passed on to CSCTF • Current format that is documented in p15 of TMB manual • each stub takes 4 bytes (two words-sized data frames) Some format change proposals are summarized athttps://twiki.cern.ch/twiki/bin/view/MPGD/TMBGEMDataFormat

3. Present TMB-to-MPC Data Format mpc0_frame1[7:0] = {clct0_cfeb[2:0],clct0_key[4:0]} -- CLCT key layer position CFEB# and half-strip# mpc0_frame1[8] = clct0_bend -- direction of CLCT bend mpc0_frame1[9] = clct_sync_err & tmb_sync_err_en[0] -- combined synchronization error flag mpc0_frame1[10] = alct0_bxn[0] -- some sort of ALCT BX flag mpc0_frame1[11] = clct_bx0 * lct0_vpf -- CLCT BX flag times LCT validity flag mpc0_frame1[15:12] = csc_id[3:0]* lct0_vpf – Trigger ID of a chamber in a trigger (sub)sector mpc0_frame0[6:0] = alct0_key[6:0] -- ALCT key layer wiregroup mpc0_frame0[10:7] = clct0_pat[3:0] -- one of 9 CLCT bend patterns (pattern ID from 2 to 10) mpc0_frame0[14:11] = lct0_quality[3:0] * lct0_vpf – LCT quality (Q=4, 9, 10 are currently unused, Q=11..15 represent amount of CLCT bending) mpc0_frame0[15] = lct0_vpf -- LCT valid pattern flag (pid != 0 ?)

4. Current TMB-to-MPC Data Format mpc0_frame0: lct0_vpf lct0_quality*lct0_vpf alct0_key clct0_pat clct_sync_err &tmb_sync_err_en mpc0_frame1: clct_bx0 *lct0_vpf alct0_bxn clct0_bend csc_id*lct0_vpf clct0_cfeb clct0_key

5. Options for Format Changes • Don’t want to increase the size of data, but to modify the existing data format only for certain chamber types that have neighboring GEM detectors, e.g., for ME11 chambers • By reducing unused and redundant information • Most important need: to extend the field for the CLCT pattern encoding to carry more fine-grained angular information about the pattern • Change 1: • Salvage 1 bit from the ALCT key field • we don't need 7 bits to encode the 48 wiregroups in ME11: • Append that 1 bit taken from ALCT key field to the extended CLCT pattern field

6. Options for Format Changes • Change 2: • Modify the meaning of the lct0_quality field • Split 1bit flag off of it to indicate whether this stub is a GEM-matched stub • Since it would not be necessary in future to use it for sorting in MPC, we can get rid of redundant pattern bending-related information in lct_quality and use one bit to tell whether this stub is a GEM-matched stub (depends on how we would want to use this LCT quality field) • (Potential) Change 4: • clct0_bend bit provides redundant information that should already be available in clct0_pat • We can swap"mpc0_frame1[8] = clct0_bend" and "mpc0_frame0[15] = lct0_vpf" bits, • and merge the "mpc0_frame1[8] = clct0_bend" bit into the CLCT pattern field

7. TMB-to-MPC Data Format with GE1/1 The option with the largest address space for the bend information(6 bits allow for 5 bits of bend amount, or 32 bend amount thresholds) lct0_hasgem mpc0_frame0: lct0_quality*lct0_vpf alct0_key clct0_gempat clct_sync_err &tmb_sync_err_en mpc0_frame1: clct_bx0 *lct0_vpf alct0_bxn csc_id *lct0_vpf lct0_vpf clct0_cfeb clct0_key

8. Options for the Quality Field Definition • As already mentioned, the original LCT Quality field carries redundant information about CLCT pattern • So we spared 1bit by getting rid of it and making the quality definition more basic • Use that separated bit to indicate GEM-matchedness • Another option: • Don’t split this bit but redefine the quality to encode the number of ALCT, CLCT, and GEM layers that were used to build this LCT stub • This info might potentially be useful in CSCTF in its multivariate PT assignment

9. TMB-to-MPC Data Format with GE1/1 An option where GEM-matchedness is integrated into the stub quality definitionthrough the number of hit layers mpc0_frame0: lct0_quality*lct0_vpf alct0_key clct0_gempat clct_sync_err &tmb_sync_err_en mpc0_frame1: clct_bx0 *lct0_vpf alct0_bxn csc_id *lct0_vpf lct0_vpf clct0_cfeb clct0_key

10. Options for the Quality Field Definition • Smaller pattern field option: • We might not really need all 6 bits (64 values) to encode the GEM-CSC pattern • But, e.g., having a separate flag to indicate GEM-matchedness might come to be very useful • Of course, there could be different other options for how to arrange the bits or what level of detail to store in them • E.g., more details could be store about #layers, or about DBX either for GEM only hits or for GEM and CSC

11. TMB-to-MPC Data Format with GE1/1 An option with a smaller GEM-CSC pattern field but with separated GEM-matchedness flag lct0_hasgem mpc0_frame0: lct0_quality*lct0_vpf alct0_key clct0_gempat clct_sync_err &tmb_sync_err_en mpc0_frame1: clct_bx0 *lct0_vpf alct0_bxn csc_id *lct0_vpf lct0_vpf clct0_cfeb clct0_key

12. Conclusion • There is some room in the current LCT data format to incorporate some GEM-related information for integrated CSC-GEM stubs • Some options were proposed • Possible constraints: • Operational: MPC and CSCTF would need to be able to deal with the new format • Evolutional: changed data format would introduce tighter dependencies between the system components • Optimizational: store only what would really be useful