1. FVTX High Multiplicity Trigger for Run15
Toru Nagashima, Yomei Fukushima
Itaru Nakagawa
Feb. 23 RadLab meeting

2. OVERVIEW
Bottom line
FPGA for FVTX trigger was implemented on South FVTX readout electronics
No interference to original FVTX readout
External parameter control (no need to change FPGA code to change the trigger condition)
Rate check with each trigger condition
Timing tune with GL1
Consistency check with hit information (Emulator)
Many things to report. In summary the FVTX trigger is almost ready, but some behaviors are still not fully understood. Currently we are evaluating the trigger efficiency.

3. FVTX trigger is about to run!
GL1 Big Scaler
New FPGA code for our trigger was implemented.
2 Trigger bits were assigned for FVTX trigger(North/South)
Observed no interference to FVTX original function. Confirmed by FVTX experts.
Currently testing our trigger only with south arm.
First of all our trigger must not interfere original FVTX readout. But it could happen since our trigger relies on existing FPGA. At the beginning it did cause small bug on FVTX standalone GUI(not on readout function, though). Also FVTX detector started on quite unstable status this year, so we had to wait for them to be ready. We were finally accepted to install our FPGA code on second week this month.

4. Trigger Parameter Controls
Trigger condition(AND,OR,# of hits etc.) has to be controllable. Parameter control is done via slow control.
DB for the parameter, GUI, and FPGA code for the slow control were prepared by Aaron Key.
We tested each function one by one
probing test pin output on FEM.
FVTX FEM test pin
e.g.) # of station control check
Set parameter on GUI
Test output2
Test output1
Test output0 1 2 3 4
We actually started with trigger code which has fixed trigger parameter, but because of the stability issue of FVTX we couldn’t do efficient test. We focused on to establish a function to control trigger parameter externally. This part was mainly done by Aaron Key. What we did is to test them and report bug of the function. One of the test we did is shown in this slide. Checked signal on test pin on FEM, and confirmed it changes when parameter control command is sent from GUI. After some debugging we could successfully establish this function.

5. Trigger Parameter Controls
Trigger parameters can be controlled using a GUI. New parameters are stored to DB and they are uploaded to the trigger FPGA within the start of run routine.

6. Trigger rate check Number of hits threshold per wedge
Moved on to check trigger rate for each trigger condition. The test was done using beam. Scanned parameters were #hits, #station, AND/OR, ADC threshold, and #FEMs. The rate changed consistently.
Number of active stations per sector

7. Trigger rate check
Trigger rate was checked scanning each parameter. Became less as the threshold became tighter.

8. FVTX Trigger Time-In w.r.t MPC Trigger
BCLK
We moved on to timing tune. As a first attempt we observed coincidence with the trigger signal from other subsystem. We adjusted the timing to MPC trigger, using oscilloscope. The correlation was actually not that clear unlike this photo. MPC trigger itself has a jitter so we couldn’t do fine tuning with scope.
MPC trigger

9. FVTX Trigger Process Time
Collision
GL1
BBCLL1
FVTX_HighMult
7 ~ 8 BCLKs IR
We can set hit waiting window to 6 or 7.
BCLK
21~22
Hit information
(11 hits/BCLK)
FVTX Trigger is well ahead of the time limit at GL1. Sufficient time to wait for hits to arrive FEM

10. Trigger Time-in using emulator
・　Measurement 1
・　Measurement 2
55 corresponds to 7 BCLKs window to accumulate hits at FEM. 11 x 7 ~77 hits/wedge.
Fired Trigger Counts/ Predicted Trigger Counts
So we tried the timing tune using the emulator. If the timing is well aligned the efficiency evaluated by the emulator should become clearly high. The emulator checks the consistency event by event so this is not only timing tune but also consistency check.
Found good trigger timing and observed some consistency with the emulator.

11. Emulator vs Fired Trigger Consistency
Trigger FPGA installed to a half of South arm
Threshold >= 5 tracks.
Low number track events are well suppressed
Good matching with predicted trigger by the emulator
- Raw track distribution
- Predicted triggered event
- Fired triggered event
Hard to see but transparent green histogram is plotted, and it is almost same as predicted trigger event. We got this result last week.
GL1 Efficiency ~ 1

12. GL1 Efficiency as of now Full South Acceptance Match/predicted match
fired
Match/Fired

13. Optimize trigger condition
Ongoing study & future plan
We are testing the trigger code using full south arm.
The efficiency is unstable(40-80%). We are trying to figure out what’s going on, and reproduce the previous result.
Things are changed since we achieved GL1 efficiency ~1. We cannot reproduce the ~100% efficiency.
Fine tuning with GL1
- Trigger timing shift run by run? ↓
Check each FEM trigger
Hot/Dead FEM?
Optimize trigger condition
Physics data taking
Output the FEM trigger into data stream.
Since we could obtain ~100% efficiency we moved on to implement our trigger code for full south arm. But it turned out the efficiency is quite unstable. Now we are trying to figure out what’s going on, and reproduce the previous result.

14. Summary Installed the trigger FPGA code on FEEs in 1008.
Established/tested external parameter control function.
Checked trigger rate for each trigger condition. Looks reasonable.
Timing tune was done using MPC trigger and the Emulator.
Observed ~100% efficiency in half arm once, but cannot reproduce. The efficiency varies between %.
Further investigation of the cause of GL1 inefficiency before physics data taking.

15. Backup

16. Emulator 3 out of 4 stations fired
Predicts if the trigger suppose to be fired or not from the given hit pattern if it matches with the trigger algorithm
FEM
DCM
Emulator
FEM
Wedge
FEM
FEM-IB
FEM
GL1
FEM
FEM
2 active FEMs

17. Phase scan

18. Phase scan

19. Mainly developed by Aaron Key (UNM)
Mainly developed by Toru Nagashima
Limited to 1bit
At least one hit in 3 out of 4 stations is required within a half sector ((Df=7.5o). -> TrackFlag.
If there are more than two tracks within a given sector (Df=15o), the second one won’t be counted.
We Request Two Trigger bits (one per arm) for FVTX trigger.

20. FVTX Trigger Timing Chart
collision
BCLK
FEM Trigger
Trigger for GL1
80ns
For timing adjustment
1 BCLK process
+ 1 BCLK Mulit FEM window
+ 1 BCLK latch　 + delay
1 BCLK process
+ 4 BCLK window
To be tested in 1008
FEM-IB
Trigger
Discri.
Delay
TTL->ECL
ECL-> TTL
RBIB
GL1
BCLK 20 9 14
17~18

21. Consistency check
When the measurement was done the trigger FPGA code was installed only on half arm.
On the other hand the emulator predicts the trigger within full arm.
- Raw track distribution
- Predicted triggered event
- Fired triggered event
We used only half arm when his measurement was done while the emulator predicts the trigger within full arm. So the inefficiency is understandable. If we cut half arm we didn’t use, we got the distribution on next slide.

22. Trigger rate check
Rack room IR
Minimum delay in 1008.
47BCLK = 15BCLK after the collision
Hit information
The trigger has a delay to wait for hit information to reach FEM from detector. Too short delay causes counting loss.
Besides the trigger threshold, I checked delay dependency of the trigger rate. Our trigger has delay as one of the controllable parameter. This is used to wait for hit information to pass through IR->FEM. If delay is too short, the trigger circuit judges if it fires or not before the hit information reaches. There should be clear jump of trigger rate around minimum delay value, and as expected, I got the result on top graph. Based on this result we decided 47 is minimum delay in This is 5BCLK longer than in test bench(vertical axis is different for top figure and bottom, but close enough here). In our understanding this is mainly because 1. trigger logic is more complicated in 1008, 2. the slow control fiber cable is shorter in test bench. (4BCLK ~ 400ns ~ 120m/c)
Result in test stand. Turn on is faster than 1008, because the fiber cable is shorter