ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren1 Physics & Astronomy HEP Electronics Matthew Warren John Lane, Martin Postranecky Resonant Triggers ATLAS SCT TIM FDR/PRR 28 June 2004

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren2 Background This is based on work by Tony Weidberg and others detailed in a paper submitted to NIM. First seen on CDF Triggers generate large variations in current in the wire- bonds of some FE components as they read-out. Triggers at rates close to the mechanical resonant frequency of the wire-bond can cause it to oscillate to breaking point. ‘Normal’ running OK as triggers are random. Calibration/Test runs can easily generate triggers at fixed frequencies – even machine runs - LHC 1 or 2 bunches = 11.2/22.4 kHz Work has been done to evaluate the effects of this problem on the SCT.

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren3 Experimental Results Resonances seen from 15kHz – 90kHz. Failures observed after a few minutes. Found NOT to have large affect on SCT – barrel orientation good, end-cap uses very short bonds But may have implications over the life- time of detector. Current frequency 17 kHz - on resonance Photo showing a wire-bond with a current of frequency 15 kHz - off resonance. SCT like wire-bonds were operated in a magnetic field (1.8T).

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren4 Role of TIM ‘Problem’ hard to fix - components are well into production – need to use ‘avoidance’ techniques. TIM is well located in the trigger tree. –Within SCT sub-detector. –Near top – a TIM fans-out trigger to 100s of modules. –Passes ROD Busy back to CTP - can provide back-pressure. TIM also source of repetitive triggers –Trigger oscillator. –Bursts of CALs TIM can provide SCT biased monitoring information on trigger rates and veto periods.

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren5 Fixed Frequency Trigger Veto (FFTV) ‘Proof-of-concept’ system developed to verify both functionality and FPGA resources consumed. Implemented in TIM FPGA2. Uses enhanced version of CDF algorithm: –Compares successive trigger periods, increments counter if matching (within programmable ‘tolerance’). –Generates a Veto when match counter hits preset limit. –Period Max setting allows passing of low-freq triggers. –Period Min setting allows high frequency trigger ‘noise’ to be ignored. Result: Works! –Small: <100 ‘slices’ out of 6900 on Xilinx Spartan II 600E –Easy to reconfigure

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren6 FFTV System Simulation Note: High Freq component ignored Freq<minFreq in window Trig Period Max Period Min Period Period Match Threshold Period Match Count Veto

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren7 Going Forward Sub-detectors should not veto triggers –(e.g. What happens to trigger number?) After discussions with Level 1 Trigger: In ‘Run-Mode’ TIM must: –Not Veto any triggers, but assert ROD Busy instead –Count the time this Veto-Busy was asserted –This will ensures L1IDs are in sync. In ‘Stand-Alone-Mode’: –TIM will veto triggers at source –L1IDs numbers then stay in order

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren8 Implementation 2x 48 bit busy clock counters added –81 day rollover. –Count Overall-busy and Veto-busy. –Reset by VME write. Setting based on experimental/calculated values: –Number triggers before Veto: 10 –Cut-off Values: Min 15kHz, Max 75kHz. –Veto Period: 1ms. Based on “toy” Monte Carlo by Tony Weidberg predicting contribution of a deadtime fraction of 3x Test Results: –Using kHz triggers we see 17% pass-through. This agrees with theory. –Still small (<200 slices) and easily configurable.

ATLAS SCT/Pixel TIM FDR/PRR28 July 2004 Resonant Triggers - Matt Warren9 Outstanding Questions Does the Veto continue until fixed-freq. triggers stop, or are small bursts allowed through? Over-ride trigger in Run-Mode? –What happens if we still see ‘dangerous’ trigger even though we have asserted a ROD Busy? Should we be able to disable it in software?