Trigger ideale: seleziona tutti gli eventi interessanti, scarta quelli che non ci interessano; Trigger reale : alta efficienza per gli eventi interessanti, bassa contaminazione Perche’ c’e’bisogno di un trigger: - Tempo morto del rivelatore: alcuni rivelatori possono non essere in grado di rispondere velocemente se due eventi avvengono troppo vicini nel tempo. Il rivelatore deve rispondere all’evento interessante. - Readout: il sistema di acquisizione dati ha un limite massimo in frequenza oltre il quale non può andare; - Storage: il data writing ha un limite massimo. E’ il limite attualmente più importante. Gli esperimenti moderni offrono informazioni dettagliate  il singolo evento è di grande size (Atlas/CMS ~ 1-2 Mbyte, ALICE ~25 MByte ). Si cerca di lavorare a Mbyte/s. Per raggiungere questo limite a LHC i trigger devono operare una selezione di un 1 evento su 40,000. IL TRIGGER Evento non interessante Evento interessante Tempo morto

Il tempo di aquisizione di un evento e’ pari a T daq. Se il rate R di eventi selezionati dal trigger e’ tale per cui 1/R non e’ piccolo rispetto a T daq  tempo morto. Quindi Il rate di eventi selezionati e’: R’/R = 1- R*T daq Il Rate di eventi spuri ( fake trigger rate ) dipende invece dalla lunghezza dell’impulso e’ dal fondo del rivelatore. Esempio: coincidenza di due rivelatori con fondo di 1 kHz, che producono un segnale lungo 20 ns. P(1) = 1000 * 20e-9 = 2e-5 ( P che in una finestra 20 ns il segnale sia on) P(1)*P(2) = 4e-10 (P* che in una finestra di 20 ns il segnale sia on su entrambi ) FTR = 4e-10 /20 e-9 s = 0.02 Hz (P*moltiplicato il numero di finestre in un secondo)

Tipica situazione da laboratorio, E’ un circuito soddisfacente ?  NO. Ritardi vari ( lunghezza dei cavi, etc.). DAQ

Tipica situazione da laboratorio, E’ un circuito soddisfacente ?  NO. Cosa succede se alla DAQ arrivano due trigger Troppo ravvicinati ? delay Come si stabiliscono I delay ? A due a due si si aggiugono/sottraggono ritardi a step costanti e si misura il rate di coincidenze delayN DAQ Cosa sono?

Tipica situazione da laboratorio, E’ un circuito soddisfacente ?  NO. Il flip-flop genera un tempo morto. delay DAQ D Q Clr Q Bisogna lasciare alla DAQ il tempo per processare il segnale  flip-flop Q Q Busy signal clr D

Tipica situazione da laboratorio, delay DAQ D Q Clr Q Busy signal Gate clk Stop Se dovessimo contare il rate di coincidenze il circuito della pagina precedente Non andrebbe bene  c’e’ un tempo morto da tenere in conto. Ovviamente potremmo andare avanti a migliorare il nostro circuito. Notate Pero’ che ogni miglioramento necessita di altri moduli da aggiungere.

..Se ad un dato istante il rate del trigger diventa elevatissimo, nel caso di Trigger NIM e’difficile comprendere la causa. Poichè non possiamo scambiare Informazioni tra il crate NIM e i nostri PC, qualsiasi controllo sull’input al Trigger e sullo stato intermedio della formazione di segnale del trigger stesso non è possibile. Allora ? Il primo problema che e’ stato affrontato e’ stato quello di fornire una maggiore Flessibilita’.Negli anni ’80 si usavano trigger realizzati con EPROM. Vantaggio  numero di canali e di logiche possibili elevate. Realizzata in genere con elettronica “NIM”. Serie di schede poste in un crate, che deve solo alimentarle a tensione oppurtuna. Una serie di limiti: - Non e’ possibile cambiare da remoto la configurazione del trigger (ambiente irradiato); - Adatta solo a logiche semplici (and/or) su pochi canali - ed inoltre.... Come si realizza un’elettronica come quella descritta nelle pagine precedenti ?

EPROM, acronimo di Erasable Programmable Read Only Memory, Memoria di sola lettura. Si puo’ cancellare tramite ultravioletti. Programmazione tramite “breakdown a valanga”: carica depositata nel gate flottante. Cancellazione tramite raggi UV. Poi arriveranno le EEPROM ( riscrivibili tramite Tensione elettrica, inizi anni ‘90).

Es: vogliamo un trigger che ci selezioni l’evento quando avviene una di queste Condizioni: - 6 piani su 10 accesi; - 5 accesi su 8 contigui esclusi il primo e l’ultimo; Rivelatore tracciante a 10 piani. Usata una EPROM 32k x 8 bit (sovrabbondante) Es = data address Bit 8 = trigger

Miglioramento rispetto alla situazione “NIM”. Adesso posso scrivere decine di Migliaia di combinazioni nella EPROM. Ho a disposizioni 8 bit ( posso usarli Per il debug, per far accendere LED, etc.). Posso mettere la scheda in un Crate “intelligente” ( camac,VME) in grado di trasmettere il pattern a un PC E memorizzarlo  ho informazioni in tempo reale sullo stato del trigger. Ma ancora non posso riconfigurare da remoto il trigger…… Vedremo nella prossima lezione quali dispositivi si possono usare Per ottenere la riprogrammabilita’ remota, diminuendo al tempo stesso il Numero di componenti utilizzati sulla scheda.

N = L  Per Atlas/CMS L = cm -2 s -1,  = cm 2,  N = 10 9 Hz = 1 GHz In un esperimento attuale non e’ piu’ possibile costituire un trigger dato Da un solo livello. Questo perche’ il rate di eventi prodotti e’ molto elevato. Ad esempio a LHC I protoni si scontreranno ogni 25 ns. Allora ho: 1 / 25 ns = 40 Mhz. SBAGLIATO Devo prendere una decisione ( si/no) ogni 25 ns. E’ chiaro che in 25 ns non posso Fare niente. Devo inventarmi qualcosa di piu’ furbo. Inoltre devo essere estremamente Veloce. Primo passo: si divide il trigger in piu’ livelli. Ogni livello abbassa il rate fino a portarlo a valori accettabili dalla DAQ. Si usano da 2 a 4 livelli di trigger.

E’ chiaro che se dovessimo aspettare la fine dei 2000 ns prima di processare un nuovo evento, vuole dire che il trigger ha efficienza di 25/2000 = 1.25 %. Bisogna andare in pipeline, una sorta di catena di montaggio, in cui ogni  t un processo analizza un dato : 25 ns Proc 1 Proc 2 Proc 3 t Un trigger di primo livella ha comunque bisogno di ns ( a LHC 300 ns solo per la lunghezza dei cavi).

Il livello 1 è implementato a livello Hw. Porta il rate da 10 9 Hz a 100 kHz. Il trigger deve prendere una decisione ogni 25 ns. A causa di tempo di Processamento dei segnali, della lunghezza dei cavi, etc. c’e’ bisogno Di un certo tempo perche’ la decisione SI/NO possa essere presa. Durante Questo tempo ( chiamato latenza), i dati vanno messi su memorie temporanee (FIFO) e mantenuti finchè la decisione non arriva. E’ chiaro che dal punto di vista Del trigger vorremmo una latenza lunga, per poter eseguire un numero sufficiente Di operazioni sui dati, dal punto di vista del rivelatore vorremmo la latency breve, Per non dover tenere troppi dati sulle memorie locali ( costo, danni da radiazione, Etc.).  compromesso necessario. Per CMS la latency è 2  s. Possono contribuire al livello L1 solo rivelatori molto veloci, capaci di dare Risposta entro pochi ns ( scintillatori, RPC, Calorimetri). Non rivelatori tipo Liquid argon, tubi a streamer, camere a deriva, etc. Front enddigitizzazionetriggerTrigger centrale Distribuzione L1 Rivelatore

Esempio di trigger di primo livello: elettrone isolato (ATLAS). ( Due celle con E t > E t *) AND E < E t ** AND or  Corresponding Hadron tower E had < Ec  Celle di un calo e.m. Trigger tower

CMS ATLAS 10 9 Hz 100 kHz 1 kHz 100 Hz 10 2 Hz LEVEL 1 ( 2  s) LEVEL 1 ( 3  s) HLT LEVEL 2 ( ms) LEVEL 3 (sec) In cosa consiste questo livello 2 di Atlas ? Hardware Mixed Software (PC FARM) Due scelte diverse: 2 livelli di trigger per CME e 3 livelli per Atlas (PC FARM)

The ROI (Region of interest) mechanism Il punto essenziale e’ la cosiddetta “ROI”. A LHC il background piu’ grande viene dalla fisica stessa. Esempio: cerco Un elettrone isolato. Ma ho una piccola probabilita’ ( piu’ grande del segnale atteso) che uno sciame elettromagnetico emetta un  0 che decade in 2 . L’algoritmo dell’elettrone isolato ne identifica e scarta la maggior parte, ma non basta. Bisogna andare a vedere se c’era la traccia dell’elettrone sui rivelatori traccianti. Problema: a livello L1 il tracking non e’ ancora disponibile Pero’ quello che L1 sa e’ dove sta l’evento interessante (region of interest)

ROI: il L2 puo’ usare le info di L1 ( localizzazione particella interessante ) per Andare ad estrarre le informazioni SOLO per quella zona. La quantita’ di dati da analizzare e’ solo l’1% del totale. Su questa zona si va a fare tracking on line. La difficolta’ di implementazione risiede nel fatto di riuscire ad analizzare tutti e SOLO I dati che ci interessano. Il tutto a 100 kHz  non banale.

Con la ROI si riesce ad ottenere una soppressione di un fattore 10. In Atlas I dati arrivano a L3 a 1 kHz in CMS ( che non ha ROI) a 10 kHz. In CMS serve una bandwidth di 500 Gbit/s e una potenza di calcolo di 5*10 6 Mips/s In CMS l’HLT e’ implementato su farm commerciali, completamente software. Essendo sw e’ molto flessibile, facilmente adattabile a qualsiasi necessita’. Uno sforzo che richiede migliaia di CPU.

IL TRIGGER DI ALICE Qui il discorso e’ un po’ diverso perche’ le luminosita’ sono molto piu’ basse Sia a p-p sia a Pb-Pb. Partiamo da rate: L max = 2*10 30 cm -2 s -1,  = cm2,  N = 2*10 5 Hz = 200 kHz, al contrario Il data size e’ maggiore ( fino a 86 MByte). In piu’, come vedremo, c’e’ il problema che per registrare con sufficiente granularita’ le decine di migliaia di tracce prodotte negli urti Pb-Pb, bisogna usare un rivelatore lento come la TPC. Il trigger e’ formato da ben 4 livelli ( 3 livelli + l’HLT). Il livello 1 deve essere fornito in tempi molto veloci ( entro 800 ns ).Viene Distribuito ai sottorivelatori entro 1200 ns. Partecipano a questo livello i rivelatori T0,V0( quarzo,scintillatori ), TOF(Bologna) e il  -arm. In p-p abbiamo una interazione ogni 25 ns. Bisogna decidere se prendere o no l’evento. Dobbiamo passare da 40 MHz ai 200 kHz, limite di funzionamento della TPC. LIVELLO 1

LIVELLO 2 LIVELLO 3 E’ la “past – future protection”. Due eventi centrali entro una certa finestra temporale comportano un veto al rivelatore. Consideriamo un evento che arriva: Devo vedere se c’e’ un’altro evento centrale entro ± 88  s. Ci si aspetta un rate di 200 Hz per gli urti Pb-Pb. T Generato dopo 6  s. Permette molti piu’ calcoli rispetto al Livello 1 (circa 240 operazioni a 40 MHz). Permette la selezione di eventi rari. HLT Completamente sw. Riduce il data volume di un ordine di grandezza in accordo col data storage bandwidth ( max 1.25 Gb/s), selezionando gli eventi interessanti.