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

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.

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.

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.

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.

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

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

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

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

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.

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

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

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.

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 40-80%. Further investigation of the cause of GL1 inefficiency before physics data taking.

Backup

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

Phase scan

Phase scan

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.

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

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.

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 1008. 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