Performance of the MuID Blue-Logic Trigger for the First p+p Run

 

H.D. Sato, Kyoto University for the PHENIX Collaboration

March 12, 2002

 

 A coarse-segmented trigger system called MuID Blue-Logic Trigger was used to trigger muons in the South Muon Arm during the first p+p run in December 2001 and January 2002.

 System overview and basic performances such as trigger rates and efficiencies will be described below.

 

1. Introduction

 

In p+p collisions at RHIC, a good trigger is a key issue for the PHENIX[i] Muon Arm since the physics trigger rate (dominated by decay pions and kaons) is roughly 1/2000 for one Muon Arm compared to the minimum-bias trigger rate.

Originally we had a plan to use the MuID Local-Level-1 (LL1) trigger which has an algorithm similar to the offline road-finder, but we could not make it for this first p+p run. We have come up with an alternative trigger system, which is much simpler and coarse, but has enough rejection power for this run. It is called Blue-Logic Trigger (or BLT) since NIM and CAMAC modules are used to make the trigger logic.

The next section describes the overview of the system design followed by summary of performances such as trigger rates and trigger efficiencies.

 

2. System Overview

 

Figure 1 shows a schematic view of the BLT.

Figure 1: Schematic view of the MuID Blue-Logic Trigger

 

The input of the BLT is 64 pseudo-trigger signals from the MuID ROCs. The output is 5 trigger bits going into the RBIB board which is the interface into the Global-Level-1 (GL1) decision for non-Local-Level-1 signals.  The whole MuID is divided into 4 quadrants, each of which issues 'Deep' or 'Shallow' trigger, and finally the number of fired quadrants at each depth is counted.

 

2.1  ROC pseudo-trigger output

 

10xx

01xx

01xx

10xx

10xx

01xx

01xx

10xx

 

Figure 2a: Segments of ROC (solid line) and pseudo-trigger output (dashed line) for each gap for vertical channels. Their bit assignments are shown altogether.

 

xx10

xx10

xx01

xx01

xx01

xx01

xx10

xx10

 

Figure 2b: Segments of ROC (solid line) and pseudo-trigger output (dashed line) for each gap for horizontal channels. Their bit assignments are shown altogether.

 

1010

A

0110

6

0110

6

1010

A

1001

9

0101

5

0101

5

1001

9

1001

9

0101

   5

0101

5

1001

9

1010

A

0110

6

0110

6

1010

A

 

Figure 2c: Overlay of figure 2a and figure 2b. Bold lines represent borders of quadrants.

 

Each MuID ROC has 96 channels (nominally) and reads out a strip of tubes (either horizontal or vertical) roughly equal to one-fourth of a gap. This is indicated for ROCs that read out vertical (horizontal) tubes in the solid-boundary regions in figure 2a (2b) above. Each ROC has two TTL “pseudo-trigger” outputs (PS0 and PS1) that are the logical or of many input signals. For a ROC reading horizontal tubes the bits have the following meaning:

  • PS0 – all East Large panel and Small Panel inputs for that ROC.
  • PS1 – all West Large panel and Small Panel inputs for that ROC.

 

For a ROC reading vertical tubes the bits have the following meaning:

  • PS0 – all Lower Panel inputs for that ROC.
  • PS1 – all Upper Small Panel inputs for that ROC.

 

This is illustrated by the dashed lines in figures 2a and 2b above.

All output signals were checked and confirmed to be working fine before finalizing the trigger configuration (Run #37939).

 

2.2 Trigger Logic and MLU (Memory Lookup Unit)

 

There are a total of 80 pseudo-trigger bits (16 per gap). It was not practical to have more than 64 inputs into the trigger algorithm due to hardware limitations in available modules. Therefore we only used the 16 bits from each of four gaps. The 16 bits from each gap are split into four groups of 4 bits – each group provides the input from a particular quadrant (because of the radial MMS field real tracks from the vertex will essentially not cross quadrant boundaries). The hit pattern from each quadrant can therefore be represented as a 16-bit address (four quadrant bits from each of the four used gaps). The 16 bits from each quadrant are converted to ECL and daisy-chained into two LeCroy 2372 Memory Lookup Units (MLUs) (for deep and shallow tracks) which output a programmed 1-bit (yes/no) output corresponding to the 16-bit pseudo-trigger input address.

The text in figures 2a and 2b above show the bit assignments of each pseudo-trigger bit within the nibble (4-bits) corresponding to a particular quadrant/gap. Note that the bits in different quadrants go to different MLUs (different 16-bit words) and can therefore have identical bit assignments. If there is a real track one expects both horizontal and vertical tubes to be hit. There are four different two-bit patterns in each quadrant corresponding to single tracks – this is illustrated in the text in figure 2c above which is obtained by overlaying figures 2a and 2b.

The nibbles from each gap for a particular quadrant are collected into a 16-bit address. If gap-0 is the most significant nibble then a track going straight through the upper-west piece of the upper-west quadrant would fire the address 0xAAAA in the upper-west MLUs. A track in the upper-central piece of the same quadrant will fire 0x6666 and a track crossing from the upper-central piece to the upper-west piece might fire 0x66AA (depending on which gap it crosses).

The allowed addresses for tracks originating from the vertex are listed in table 1 below. Each pattern has 8 bits on, corresponding to horizontal and vertical hits in each gap. Either 6 or 7 of these bits are required to fire (depending on the number of missed hits allowed). All other bits are treated as “don’t care”, i.e., any number of additional hits is allowed.

 

0x5555

0x6666

0x9999

0xAAAA

 

0x5556

0x5559

0x555A

0x666A

0x999A

0x5566

0x5599

0x55AA

0x66AA

0x99AA

0x556A

0x559A

 

 

 

0x5666

0x5999

0x5AAA

0x6AAA

0x9AAA

0x566A

0x599A

0x56AA

0x59AA

 

 

Table1: All allowed addresses for each quadrant MLU. 4 bits (represented by one hex-number) are for each gap counting from the shallowest gap. Bit assignment for each gap is shown in figure 2c.

 

‘Shallow’ MLUs and ‘Deep’ MLUs have different ‘Last penetration gap’ and ‘Number of missed hits allowed’. Final configuration is summarized below. For ‘Shallow’ MLUs, bits for deeper gaps are ignored. For example, 0x5500 is accepted.

 

Trigger

Last Gap

Number of Missed Hits

Deep

4

2

Shallow

2

1

Table 2: Final MLU configuration after Run #38189. Before that run, {Last Gap = 4, Missing Hits = 1} was used for the Deep trigger where the gap number is counted from 0.

 

Since we could use only 16 ROCs out of 20 for each orientation, we had to decide which gap should be excluded from the trigger decision. We have chosen gap 1 (second gap) for it since

l         Gap 2,3, and 4 are important for the Deep trigger

l         0-2-3-4 configuration has a longer lever arm than 1-2-3-4 configuration. And it is also known that 1-2-3-4 configuration will suffer from more background of low-angle tracks than 0-2-3-4.

Now we have 8 outputs from these MLUs (4 for Deep and 4 for Shallow triggers). These 8 signals go into another MLU which is called the 'Decision' MLU which has 5 output signals.

They are

l         1 Shallow (1S)

l         2 Shallow (2S)

l         1 Deep (1D)

l         1 Shallow and 1 Deep (1D1S) and

l         2 Deep (2D).

 

Trigger logic is obvious.

Note: in the logic, 'Deep' always include 'Shallow'.

 

2.3 Delay tuning before GL1 input

 

5 output signals from the 'Decision' MLU (actually a 16-channel ribbon cable was used with 11 unused channels) go into the electronics room where GL1 board exists. Before GL1 input, we had to adjust the timing for each bit since a BLT signal arrives much earlier than a GL1 accepted signal. First we used gate-delay generators (GDGs) for that purpose. Timing was tuned with 'Hardware-software triggers matching' method. This method compares trigger bits into GL1 ('Hardware' triggers) and trigger bits generated by the trigger emulator ('Software' triggers), then tests their consistency. Detail will be described in the later section.

We scanned the delay for every 20nsec for 1D signal and found the optimized point.

Finally delay value was set to about 1.3 micro seconds. Timing difference with other trigger bits are minimal (less than 5nsec).

In this run, we have used the 'Slow gas' mode, where all MuID tube signals fall into two consecutive beam clocks. That means we need two pulses, one is 1 beam clock = 106nsec delayed from the other, for all 5 triggers. Otherwise, we can not achieve efficiency close to 100%, but only about 50%. We have abandoned 2S signal which is less important than others, so finally we have sent 8 trigger signals into GL1. It was confirmed that about 99% efficiency ('Trigger-Circuit efficiency' as described later) was achieved when beam condition was good. But when the raw trigger rate went up due to bad beam condition, Trigger-Circuit efficiency became worse because of dead time of GDG. So we have replaced two GDGs for 1D signal with cable delays, which made trigger efficiency more stable. Other triggers continued to use GDGs since: 1S is not a physics trigger but for the background study and rates are small enough for 1D1S and 2D even when beam condition is bad. Details about trigger rates and trigger-circuit efficiencies will be described in later sections.

 

3. Trigger Rates

 

PHENIX has achieved the DAQ rate (data on disk) of about 60Mbyte/sec at maximum for this run. Data size of a p+p event was about 50kbyte. So the trigger rate (including all triggers) should be less than about 1 kHz. Actually, when the trigger rate went up above 800Hz, DAQ busy time started getting worse. So we have set our threshold to 800Hz and tried to reduce higher rate triggers if it is exceeded.

Except muon related triggers, we had beam clock trigger (about 150Hz), minimum bias interaction trigger (200-300Hz) and photon/electron related triggers. Muon related triggers are

l         Physics Triggers

Ø        1D*MB (Minimum Bias) for the single muon trigger

Ø        1D1S*MB for the dimuon trigger

l         Triggers for Background Studies

Ø        1S*MB for the muon background study (hadron punch through)

Ø        1D*(Yellow Ring Empty OR Blue Ring Empty)*MB for the beam gas/scraping background study, which was replaced with 1D (raw) for later runs.

'Minimum bias' or 'MB' means (Beam-Beam Local-Level-1 OR NTC-wide). 'A*B' means coincidence of A and B.

These trigger rates varied significantly with the beam conditions. When it was normal, 1D*MB rate was less than 100Hz. In this case, we didn't need any pre-scale for it. But when beam condition got worse, it went up above 1 kHz which made DAQ scream. So we have prepared two configurations in GL1 for 1D*MB trigger. They are identical except that one is without pre-scale factor and the other is with pre-scale factor = 4 (which means 1/5 of triggered events are written in disk), so that shift person can choose one of them according to the beam condition. MB rate was rather stable and typically 10~20 kHz.

 

Figure 3:  Time dependence of Relative Trigger Rates

 

Figure 3 shows various ratios for major triggers as a function of time (date). It's clearly shown that MuID (means 1D*MB) / BBLL1 varies significantly more than others. This means 1D*MB rate is unstable since it was shown that BBLL1 is much stable against beam background (shown later).

Rates of 1D (raw) and 1D*MB were compared and they are highly (linearly) correlated. That indicates that 1D*MB rate is dominated by non-collision related events as well as 1D (raw).

Rate of 1D1S*MB is roughly 1/10 of 1D*MB, so we did not need any pre-scale factor for it throughout the entire run period..

We have found that unstable trigger rates were mostly due to the beam scraping background with the following study done on January 21, 2002.

Ø        Cog and steer beam as usual for physics run.

Ø        Put beam collimators in the RHIC ring to scrape beam

Ø        Miss-steer beam      

Ø        Take collimators out

Ø        Put polarimeter targets in each Ring and take them out

Ø        Put beam collimators again

Ø        Dump the beam

 

Figure 4: Time dependence of trigger rates during MuID beam background study

 

Figure 4 shows time dependence of rates for each trigger during MuID beam background study. And table 3 shows numbers for the first three steps.

Action

BBLL1

NTC- narrow

MuID1D(raw)

MuID1D(cosmic rays subtracted)

Cog and steer beam

10.6k

5.2k

10.9k

9.1k

Put in beam collimator

10.3k

4.8k

3.1k

1.2k

Miss-steer beam

1.6

78

3.2k

1.3k

Table 3: Procedure and rates for each trigger during the beam background study (First three steps only)

 

From the first and second step, MuID1D raw rate reduced significantly. Since the rate from cosmic rays is 1.9 kHz, it is reduced significantly from 9.0 kHz to 1.2 kHz when cosmic rays subtracted, which gives us the upper limit of the beam gas rate. On the contrary, BBLL1 and NTC rates remain almost same, which means scraping beam does not affect the collision rate and just reduces the beam scraping background which contributes to the MuID trigger rate much.

From the second step to the third, BBLL1 and NTC rates reduced significantly, while MuID rate remained almost same. This again tells us that most of MuID-triggered events are not collision related. It also tells us how much beam gas or beam scraping background contaminate

BBLL1 and NTC trigger (about 10-4 for BBLL1 and10-2 for NTC-narrow).

It is also confirmed that the collimator works to reduce the MuID (raw) trigger rate when the beam is blown up by a polarimeter target.

 

4. Trigger-Circuit Efficiency

 

'Trigger-Circuit (TC) Efficiency' is defined as (number of events with both 'hardware' and 'software' trigger fires) divided by (number of events with 'software' trigger fires). Definitions of 'hardware' and 'software' triggers were described before.

Inefficiencies will arise from

1.         Dead time due to delay before GL1

2.         Hardware and/or timing problem (compared to Data FIFO) for the ROC pseudo-trigger output 

We have not studied the item 2 systematically, but following results indicates that the item 1 is the main contribution to the inefficiency.

Simple estimation:

MuID1D raw rate varied from 3 kHz to 30 kHz (sometimes 100 kHz) according to the beam condition as described in the previous section. So the accidental rate is

(3 ~ 30 kHz) ´1.3 micro sec = (0.4 ~ 4) % inefficiency.

 

Figure 5: Time (Run number) dependence of Trigger Circuit efficiency. Statistical errors are 0.02~0.03 for 1D and 0.05~0.1 for 1D1S.

 

Figure 5 shows TC efficiency as a function of the Run number. Not all of runs were shown here. Statistical errors are 0.02~0.03 for 1D and 0.05~0.1 for 1D1S. For most of runs shown here, TC efficiency is over 96% for 1D and over 98% for 1D1S. Some fluctuations in 1D are correlated with the trigger rate (Thus the beam background rate). These inefficiencies look consistent with the rough estimation due to dead time above.

Since Run #39780, cable delays had been used instead of GDGs, which made 1D-efficiency higher and as good as 1D1S.

Figure 6: Correlation between Trigger-Circuit efficiency and relative trigger rate (compared to BBLL1) of MuID1D as a function of Run number.

 

 Figure 6 shows comparison of trigger rate of MuID1D*MB relative to that of MB = (BBLL1 OR NTC wide) and TC efficiency as a function of Run number. MuID1D*MB rate is almost same as the accidental rate of MuID1D (raw) and MB, and about MuID1D (raw) rate ´ 106nsec ´ 2. Then inefficiency due to dead time of GDG is about MuID1D (raw) rate ´ 1.3 micro sec ~ MuID1D*MB rate ´ 6.3 when cable delay was used. For example, TC inefficiency will be 3% when the relative rate is 0.005 and 9% when the relative rate is 0.015. This simple estimation is consistent with results in figure 5. After Run #39780 (cable delay), efficiency looks independent of trigger rate.  

 

6. Muon Trigger Efficiency

 

Simulation shows that muon trigger efficiency is almost 100% if muon momentum is good (above 2.5 GeV/c) and within Muon Arm acceptance when the chamber efficiency is 100%. When the chamber efficiency is 90%, muon trigger efficiency is estimated to be about 83%. We are now working to obtain channel-by-channel (or panel-by-panel) chamber efficiencies from real data to get more realistic muon trigger efficiencies.

 

7. Summary

Overview of MuID Blue-Logic Trigger used for the last p+p run was presented as well as its basic performance. Trigger rate was low enough for dimuon trigger (1D1S*MB), but for single-muon trigger (1D*MB), we sometimes needed to introduce pre-scale factor 4 because of unstable beam scraping background, which was shown to come from blown-up beams. Trigger-circuit efficiency was over 96% for single-muon and 98% for dimuon trigger. Inefficiencies are consistent with dead time in the gate-delay generators. Muon trigger efficiency is now being studied.

 

8. Acknowledgement

We will thank C-AD group, especially to Angelika Drees who has cooperated in the beam background study.

 

Appendix A. Code Documentation

 Codes for trigger emulator exist for both online and offline. Online codes can be found in online/monitoring/phnxmonitor/muid/pseudo_trig/ directory of CVS. Offline codes are mMuiPseudoTrigger.cc and mMuiPseudoTrigger.h which are found in offline/packages/mui/ directory of CVS. Its output, dMuiPseudoTrigger is stored in a DST.

MLU mapping files are found in the online directory or offline/packages/mui/wrk/ directory in CVS. They are mui_pseudotrigmap_deep_mh1.dat and mui_pseudotrigmap_deep_mh2.dat for Deep MLUs and mui_pseudotrigmap_shallow.dat for Shallow MLUs. They can be created only with online codes currently. The following shows how to:

1.         Compile codes in the online directory shown above.

2.         Start ROOT.

3.         type “gSystem->Load(“libdesicion.so”)

4.         type “generate_mlu_data( char* output_file_name, int last_plane, int missed_hits )” for the ‘Quadrant’ MLUs and “generate_decision_mlu_data( char* output_file_name) for the ‘Decision’ MLU.

All file names and their directories above are subject to be changed.



[i] http://www.phenix.bnl.gov/