-- TaoHuang - 2019-02-08

This twiki is dedicated to GEM+CSC OTMB FW development. It includes the steps to develop and test CCLUT + full GEM+CSC algorithm during LS2. High multiplicity trigger is also added to Run3 OTMB FW.

Red led --> PENDING
Yellow led --> IN PROGRESS
Green led --> DONE

Things that are not clear yet are highlighted in RED.

Linux shell commands are highlighted in YELLOW

Linux shell output is highlighted in AQUA (blue)

Verilog/C/C++ code is highlighted in LIME (green)

HMT, CCLUT and format change

High multiplicity trigger (HMT) for hadronic showering in CSC

HMT description DN-20-033

Long-lived signature decay can finally result in hadronic showering in muon system and leave lots of hits in one chamber. If number of hits in one chamber is much high than usual, then it could be a sign of long-lived signature.

The current CMS trigger did not work efficiently for this special signature and the new trigger is proposed: count the number of hits in each single chamber and compare with thresholds set for hadronic showering.

Firmware implementation in OTMB FW:

  • in each BX, count the comparator hits
  • align the number of hits value with LCT construction if CLCT is found, otherwise delay this signal to the nominal BX position
  • Three thresholds for hadronic showering trigger: loose,median, tight. Compare the number of hits with three thresholds and calculate the 2bits results of this local trigger
    • 2bits = 2'b00: failed all three thresholds
    • 2bits = 2'b01: only pass the loose thresholds
    • 2bits = 2'b10: pass loose and median thresholds
    • 2bits = 2'b11: pass all three thresholds
  • transmit the 2bits trigger result per BX information to downstream (->MPC->EMTF)

New registers for HMT

ADR bits name initial type description
0x1AC [0:0] hmt_enable 1 RW 0=HMT disable; 1 = HMT enable
[1:1] hmt_me1a_enable 1 RW 0=HMT disable for ME1a; 1 = HMT enable for ME1a
[11:2] hmt_trig_nhits 0 R comparator hits count in the chamber for HMT
[13:12] hmt_trigger 0 R HMT trigger results: nhits passing 3 HMT thresholds
0x1AE [9:0] hmt_thresh1 90 RW loose HMT threshold
[10:10] hmt_thresh1_pass 0 R pass loose threshold or not: 0=fail; 1=pass
0x1B0 [9:0] hmt_thresh2 95 RW median HMT threshold
[10:10] hmt_thresh2_pass 0 R pass median threshold or not: 0=fail; 1=pass
0x1B2 [9:0] hmt_thresh3 100 RW tight HMT threshold
[10:10] hmt_thresh3_pass 0 R pass tight threshold or not: 0=fail; 1=pass

CCLUT Algorithm and Run3 data format change

Detector note describing the CCLUT algorithm: DN-19-059
Legacy Run2 CLCT pattern. pattern ID from 2-10
New Run3 CLCT pattern. pattern ID from 0-4
UCLA group proposed new pattern definition to improve the CLCT performance: better resolution and slightly better efficiency. The original idea from TAMU is to fit on the comparator digi on all 6 layer in CSC chamber but it is only suitable for offline analysis. In term of firmware implementation, the realistic algorithm is to use patterns and LUT to find CLCT with better resolution.

As seen in the above pattern definition, in total 5 fat patterns are proposed and each layer has 3 possible position. With case of missing hit, then finally 2bit is used to encode the hit situation in each layer and 12bits comparator code for one track. The 12bits comparator code together with key halfstrip can record full information of one local track, which means that 12bits comparator code can be mapped to position and bending of local track from fitting on comparator hits. Offline studies derive the set of LUTs to map 12bits comparator code into better position and bending of the local track.

Firmare implementation detail in OTMB:

  • The CCLUT is turned on by macro definition in new OTMB fw
  • Update the pattern definition in pattern_finder module
  • use pattern finding algorithm to find pretrigger and trigger as uaual while keep track of hit position in each relative to key halfstrip and calculate the comparator code for each trigged pattern
  • sort the trigger pattern by number of layer with hits and pattern ID (0-4). Select the two best triggered patterns as two CLCTs
  • meanwhile, map the comparator code of CLCTs into position offset and bending. The position offset plus the key halfstrip of pattern gives the 1/8 strip level resolution

New registers for CCLUT and format change

ADR bits name initial type description
0x1AA [0:0] ccLUT_enable - R 0=CCLUT disable; 1 = CCLUT enable
[1:1] run2_trig_format_enable 0 RW 1= enabled run3 trigger format; 0 = disabled, use run2 trigger format
[2:2] run2_daq_format_enable 0 RW 1= enabled run3 daq format; 0 = disabled, use run2 daq format
0x19A [11:0] CLCT0_CC - R 1st CLCT comparator code
0x19C [11:0] CLCT1_CC - R 2nd CLCT comparator code
0x19E [8:0] CLCT0_QLT - R 1st CLCT new quality
0x1A0 [8:0] CLCT1_QLT - R 2nd CLCT new quality
0x1A2 [3:0] CLCT0_BND - R 1st CLCT new bending
0x1A4 [3:0] CLCT1_BND - R 2nd CLCT new bending
0x1A6 [9:0] CLCT0_XKY - R 1st CLCT new position, 1/8 strip precision
0x1A8 [9:0] CLCT1_XKY - R 2nd CLCT new position, 1/8 strip precision

CSC local trigger (A.K.A LCT )data format change

Detector note with description of GEM and CSC trigger data formats for Run-3: DN-20-016

As HMT, CCLUT and GEMCSC algorithms were developed for OTMB firmware, the new trigger data format is proposed to send out high quality trigger data to downstream and improve the trigger performance. Trigger data format change in firmware is controlled by run3_trig_format_enable

DAQ data format change

As HMT, CCLUT and GEMCSC algorithms were developed for OTMB firmware and new trigger data fornat, the DAQ stream is also updated to better incorporate the changes and send out high quality data.

  • The MPC frame (namely two LCTs) is synchronized with trigger data format change.
  • The comparator code of CLCT from CCLUT is added for CCLUT algorithm.
  • GEM information like: GEM synchronization is added
  • GEM copad match
  • GEM data is added to OTMB DAQ stream
  • GEMCSC match results

New revision code of OTMB FW is also proposed:

  • [4:0] 5bits for major Version (major features which breaks compatibility, requires changes to other board firmware)
  • [8:5] 4bits for minor version (minor features, internal fixes, bug fixes, etc).
  • [12:09] 4bits for DAQ format type: 0 for old TMB, 1 for Run2 legacy OTMB, 2 for Run3 OTMB with CCLUT and CSConly, 3 for Run3 OTMB with CCLUT and GEM ( ??? Run3 TMB with CCLUT?? )
OTMB DAQ data format change in firmware is controlled by run3_trig_format_enable

Run3 OTMB DAQ format would be on github: https://github.com/csc-fw/otmb_fw_docs

OTMB headers are summarized in following table

Header Legacy Run2 Run3 changes note
Header7 firmware_revcode[14:0] firmware_revcode[14:0] since Run3 update revision code definition
Header8 pretrig_counter[29:15] HMT_nhits[0], CLCT0_xky[1:0], CLCT0_CC[11:0] first bit of HMT_nhits; CCLT0_xky[1:0] is 1/4 strip bit and 1/8 strip bit, CC=comparator code
Header12 clct_counter[29:15] gems_sync, gemB_sync, gemA_sync, gemB_overflow, gemB_overflow, gemB_vpf, gemA_vpf, copad_match[7:0] gems_sync for gemA+gemB synchronization, copad_match[7:0] represents copad matching status of 8 clusters in gemA
Header14 trig_counter[29:15] HMT_nhits[1], CLCT1_xky[1:0], CLCT1_CC[11:0] second bit of HMT_nhits; CCLT1_xky[1] is 1/4 strip bit and CLCT1_xky[0] is 1/8 strip bit, CC=comparator code
Header16 alct_counter[29:15] alct_gem_win[2:0], gem_clct_win[3:0],gem_delay[7:0] alct_gem_win is alct in alct-gem match window, gem_clct_win is gem in gem_clct match window, gem_delay is gem delay for alct-gem match
Header 25/26 CLCT0/CLCT1 Run3 CLCT0/1 Update two CLCTs with CCLUT algorithm
Header30 alct_bxn[4:0] HMT_nhits[6:2] most significant 5 bits for HMT_nhits
Header31/32/33/34 MCP frames Run3 MPC frames MPC frames are two LCTs and new MPC frames are two Run3 LCTs
Header36 RPC fifo control fifo_pretrig_gem[4:0], fifo_tbin_gem[4:0], GEM_zero_suppress+GEM_enable[3:0] GEM readout control and 4 GEM fibers enabled or not
Header 40 MXCFEB==7 gem_csc_bend_enable gem_csc_bending is enabled or not. if so, bending in LCT is reported by gem-csc bending, rather than CSC internal bending
OTMB with HMT+CCLUT+GEMCSC algorithm (ME1/1 and ME2/1) would include all above changes. The OTMB with HMT+CCLUT (ME3/1 and ME4/1)and TMB with HMT+CCLUT(all other stations with TMB board) would only include the changes for CCLUT+HMT.

Red led Victor would work on new unpacker with proposed new DAQ format

Red led New DQM plots were also supposed to be added when new DAQ data format starts to work. The list of observations/measurements in DAQ to monitor:

  • comparator codes
  • LCT properties: 1/8 strip position. quality, bending
  • HMT Nhits and trigger results (2bits)
  • GEM synchronizations:
  • GEM clusters
  • GEM-CSC match: ALCT location in GEM window, GEM location in CLCT window ? GEM-ALCT-CLCT pulse match ?

GEMCSC Trigger development

Detector note on the CSC local trigger algorithm and the GEM-CSC integrated local trigger algorithm (from CMSSE Emulator): DN-19-054

Firmware development is described in this page.

GEM+CSC local trigger test stand

GEMCSCTeststand b904.jpeg
GE1/1 and ME1/1 test stand at b904
GEMCSCteststand sketchup b904.png
GE1/1 and ME1/1 test stand at b904

GEM-CSC communication

To synchronize the GEM RX with main clock, inside OTMB firmware, two phase shifters were added, one for gemA and one for gemB. However, in real gemA and gemB are grouped together and therefore the phase shifter for gemA is used for whole GEM superchamber (for ME1/1, one phase shifter for ME1/b part with 4 DCFEBs and one for ME1/a part with 3DCFEBs). To control phase shifter, configurable variables, gem_rx_delay, gem_fine_delay and gem_pogneg are added to configuration. gem_rx_delay is to control the phase shift at nano second unit and gem_fine_delay is to control the phase shift at 0.1 nanosecond unit. gem_posneg is to chose falling edge of main clock(gem_posneg=0) or rising edge of amin clock(gem_posneg=1) . CSC Emulib has a function to convert gem_rx_delay and gem_fine_delay into 8-bits phase shift value used for firmware: 8-bits phase shift = (int) {(gem_rx_delay + gem_fine_delay/10.0)* 256.0/25}

GEM+CSC data DAQ path readout

GEM data in OTMB DAQ path: GEM RAW hits. OTMB Headers is described above.

An new unpacker is developed to unpack the GEM+CSC data from OTMB:

New registers for GEM related features

ADR bits name initial type description
0x300/0x302/0x304/0x306 [0:0] gem_gtx_rx_enable[igem] 1'b1 RW Enable this GTX optical input (0 puts GTX in reset state)
[1:1] gem_gtx_rx_reset[igem] 0 R reset the sync stage of this GTX
[2:2] gem_gtx_rx_en_prbs_test[igem] 0 R Select this GTX for PRBS test input mode
[3:3] gem_rx_sync_done[igem] 1 R 1= rx_sync_done, gtx ready
[4:4] gem_link_good[igem] 1 R link stability monitor: TRUE indicates this link has been stable for at least 15 BX
[5:5] gem_link_had_err[igem] 0 R link stability monitor: TRUE indicates an error happened at least once on this link
[6:6] gem_link_bad[igem] 0 R link stability monitor: TRUE indicates that errors happened over 100 times on this link
[7:7] gem_rx_pol_swap[igem] 0 R 1= GTX has swapped rx board routes
[15:8] gem_rx_err_count[igem] 0 R rx error count
0x308 [0:0] gem_rxd_fire 0 RW Set new phase, software sets then unsets
[1:1] gem_rxd_reset_phase 0 RW Reset current phase to 32
[2:2] gem_rxd_busy 0 R 1=phaser is busy
[3:3] gem_rxd_lock 0 R DCM lock status
[6:4] gem_rxd_sm 0 R Phase shifter machine state
[7:7] gem_posneg 0 RW 0=latch inter-stage on falling main clock edge; 1=latch inter-stage on rising main clock edge
[15:8] gem_rxd_delay 31 RW Phase delay to latch data received from GEM, approximately 0.1ns steps (clock period/256)
0x30A [0:0] gemB_rxd_fire 0 RW Set new phase, software sets then unsets
[1:1] gemB_rxd_reset_phase 0 RW Reset current phase to 32
[2:2] gemB_rxd_busy 0 R 1=phaser is busy
[3:3] gemB_rxd_lock 0 R DCM lock status
[6:4] gemB_rxd_sm 0 R Phase shifter machine state
[7:7] gemB_posneg 0 RW 0=latch inter-stage on falling main clock edge; 1=latch inter-stage on rising main clock edge
[15:8] gemB_rxd_delay 31 RW Phase delay to latch data received from GEM, approximately 0.1ns steps (clock period/256)
0x30C [0:0] gem_debug_fifo_reset 0 RW reset gem fifo debug
[2:1] gem_debug_fifo_sel 0 RW select cluster: 0,1,2,3
[4:3] gem_debug_fifo_ctrl_igem 0 RW select gem fiber: 0,1,2,3
[14:5] gem_debug_fifo_ctrl_adr 0 RW fifo address
[15:15] gem_debug_fifo_ctrl_wr 0 - NOT USED
0x30E [15:0] gem_debug_fifo_data 0 R GEM raw hits data from fifo
0x310 [4:0] gem_fifo_tbins 7 RW Number GEM FIFO time bins to read out
[9:5] gem_fifo_pretrig 2 RW Number GEM FIFO time bins before pretrigger
[10:10] gem_fifo_decouple 0 RW 1=Independent gem tbins, 0=copy cfeb tbins
[11:11] gem_read_enable 0 RW GEM readout enable in OTMB DAQ
[12:12] gem_zero_supress_enable 0 RW 1=GEM Zero-supression enabled
[15:13] - - - NOT USED
0x312 [3:0] gemA_rxd_int_delay 0 RW GEMA Rxd Integer BX Delay. ?? does it apply to GEM data ?
[7:4] gemB_rxd_int_delay 0 RW GEMB Rxd Integer BX Delay. ?? does it apply to GEM data ?
[8:8] decouple_gem_rxd_int_delay 0 RW 1=GEMA/B use independent Rxd BX delay; 0=GEMA/B both use gemA_rxd_int_delay
[12:9] gem_readout_mask 4'b1111 RW enable readout for each fiber: 1=enabled, 0=disabled for one fiber
[15:15] - - - NOT USED
0x314 [0:0] gem_cnt_all_reset_vme 0 RW 1=reset all counter
[1:1] gem_cnt_snapshot 1b0 RW 1=take snapshot of current count
[2:2] gem_cnt_stop_on_ovf 1b0 RW 1=stop all counters if any overlow
[3:3] unganged_counter_controls 1b0 RW 1=Ungang GEM and TMB counter setting
[4:4] gem_cnt_clear_on_resync 1b0 R At least counter overflowed
[5:5] gem_cnt_ctrl_wr[5] 1b0 - unused
[6:6] gem_cnt_clear_on_resync 1b0 RW 1=Clear VME counters on ttc_resync
[7:7 ] gem_cnt_ctrl_wr[7] 1b0 - unused
[8:8] gem_cnt_adr_lsb 1b0 RW 0=read counter lower 16 bits, 1=upper 14 bits
[15:9] gem_cnt_select 7b0 RW counter address
0x316 [15:15] gem_cnt_rdata 0 R GEM counter value
0x318 [4:0] gem_clct_deltahs 8 RW GEM-CLCT position match window , unit is halfstrip
[7:5] gem_clct_deltawire 1 RW GEM-ALCT position match window , unit is wiregroup
[8:8] gem_clct_enable 1 RW GEM-CLCT match enable
[9:9] gem_alct_enable 1 RW GEM-ALCT match enable
[15:10] - - - not used
0x320 [0:0] gem_inj_wen 1 RW injector reset
[2:1] gem_inj_sel 2'b0 RW cluster select
[4:3] gem_inj_igem 2'b0 RW GEM fiber select
[14:5] gem_inj_adr 10'b0 RW address
[15] gem_inj_mask 1'b0 RW inject enable
0x322 [15:0] gem_inj_data 16'b0 RW GEM raw hits data
0x324 [0:0] gem_match_neighborRoll 1'b1 RW gemA and gemB match allow to use neighbor Rolls (namly +/- 1 Roll window)
[3:3] gem_match_neighborPad 1'b1 RW gemA and gemB match allow to use neighbor Pads
[7:4] gem_match_deltaPad 4'b10 RW gemA and gemB match window in term of num of pads
0x326 [5:0] gemA_bx0_delay 6'b0 RW gemA BX0 delay compared to OTMB BX0
[6:6] gemA_bx0_enable 1'b1 RW enable gemA+OTMB BX0 match
[7:7] gemA_bx0_match 1'b0 R gemA+OTMB BX0 match status: 0=no match, 1=matched
[13:8] gemB_bx0_delay 6'b0 RW gemB BX0 delay compared to OTMB BX0
[14:14] gemB_bx0_enable 1'b1 RW enable gemB+OTMB BX0 match
[15:15] gemB_bx0_match 1'b0 R gemB+OTMB BX0 match status: 0=no match, 1=matched
0x328 [3:0] - 4'b0 RW NOT USED
[7:4] match_gem_alct_window 4'd3 RW GEM-ALCT match window size in timing, unit=BX
[11:8] match_gem_clct_window 4'd5 RW GEM-CLCT match window size in timing, unit = BX ?? maybe finally just use alct_clct_win_size?
[12:12] gemA_alct_match 1'b0 R status of gemA+ALCT match: 1=matched, 0=not matched
[13:13] gemA_clct_match 1'b0 R status of gemA+CLCT match: 1=matched, 0=not matched
[15:14] gemA_fiber_enable 2'b11 RW enable gemA fibers for gemcsc match or not
0x32A [7:0] match_gem_alct_delay 8'b0 RW gem delay fro gem-ALCT trigger match. unit=BX
[11:8] - 4'b0 RW not USED
[12:12] gemB_alct_match 1'b0 R status of gemB+ALCT match: 1=matched, 0=not matched
[13:13] gemB_clct_match 1'b0 R status of gemB+CLCT match: 1=matched, 0=not matched
[15:14] gemB_fiber_enable 2'b11 RW enable gemB fibers for gemcsc match or not
0x32C [10] tmb_copad_alct_allow 1'b1 RW tmb allows Copad+ALCT match when CLCT is missing
[11] tmb_copad_clct_allow 1'b0 RW tmb allows Copad+CLCT match when ALCT is missing
[14] gemcsc_bend_enable 1'b1 RW use gem-csc bending angle rather than CSC internal bending for LCT
0x33A, 0x33C, 0x33E - gem_vfat_hcm0/1/2 16'hFFF RW GEM hot VFAT mask. 0x33A for gemA VFAT0-15; 0x33C for gemB VFAT0-7+gem VFAT16-23; 0x33E for gemB VFAT 8-23
0x340 - 0x34E - gemA clusters - R [13:0] for gemA cluster0-7. for 0x340, [14] is for gemA_overflow, [15] is for gemA_sync
0x350 - 0x35E - gemB clusters - R [13:0] for gemB cluster0-7. for 0x350, [14] is for gemB_overflow, [15] is for gemB_sync
0x360 - 0x36E - copad clusters - R [13:0] for copad cluster0-7. for 0x360, [14] is for copad_sync

GEM, CSC alignment and its impact on GEM-CSC matching

Incorporating alignment effect in FW

GEM-CSC bending angle calcualted at OTMB and LCT sorting

Proposed Run3 OTMB configuration summary

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpeg GEMCSCTeststand_b904.jpeg r1 manage 241.4 K 2019-02-08 - 18:09 TaoHuang  
PNGpng GEMCSCteststand_sketchup_b904.png r1 manage 98.9 K 2019-02-08 - 18:09 TaoHuang  
PNGpng Run2CLCTPattern.png r1 manage 66.4 K 2020-12-12 - 07:56 TaoHuang  
PNGpng Run3patterns.png r1 manage 101.5 K 2020-12-12 - 07:56 TaoHuang  
Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r13 - 2021-03-11 - TaoHuang
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback