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

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 manualTMB manual – each stub takes 4 bytes (two words-sized data frames) Some format change proposals are summarized at https://twiki.cern.ch/twiki/bin/view/MPGD/TMBGEMDataFormat https://twiki.cern.ch/twiki/bin/view/MPGD/TMBGEMDataFormat

3. Present TMB-to-MPC Data Format 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 ?) 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

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

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 07815 alct0_keyclct0_gempat lct0_quality* lct0_vpf lct0_hasgem 07815 clct0_cfeb lct0_vpf csc_id * lct0_vpf mpc0_frame0: mpc0_frame1: clct0_key clct_sync_err & tmb_sync_err_en alct0_bxn clct_bx0 * lct0_vpf 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)

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 07815 alct0_keyclct0_gempat lct0_quality* lct0_vpf 07815 clct0_cfeb lct0_vpf csc_id * lct0_vpf mpc0_frame0: mpc0_frame1: clct0_key clct_sync_err & tmb_sync_err_en alct0_bxn clct_bx0 * lct0_vpf An option where GEM-matchedness is integrated into the stub quality definition through the number of hit layers

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  BX either for GEM only hits or for GEM and CSC

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

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