Pixel: Elettronica di Front End Roberto Beccherle, INFN - Genova Incontro ATLAS e CMS per l'Upgrade a SLHC, Sestri Levante, 13 – 14 Novembre 2008.

Presentazione sul tema: "Pixel: Elettronica di Front End Roberto Beccherle, INFN - Genova Incontro ATLAS e CMS per l'Upgrade a SLHC, Sestri Levante, 13 – 14 Novembre 2008."— Transcript della presentazione:

1 Pixel: Elettronica di Front End Roberto Beccherle, INFN - Genova Incontro ATLAS e CMS per l'Upgrade a SLHC, Sestri Levante, 13 – 14 Novembre 2008

2 Motivazioni dell’Upgrade e stato dei lavori del circuito di Front-End 1.Il rivelatore attuale 2.Scenari per l’upgrade 3.Simulazioni 4.Nuova elettronica 5.Insertable B-Layer (IBL) 6.Conclusioni

3 Pixel di ATLAS: il modulo 46.080 Pixels e Sensore. 16 Chip di FE (IBM 0.25 µm). Module Controller Chip (MCC) che effettua la configurazione e l’Event Building. Flex Hybrid: capacità di disaccop- piamento, NTC, MCC e connettore. Le connessioni elettriche sono “LVDS” - Input: Clock e Dati. - Output: DataOut1 and DataOut2. - AVDD, DVDD, AGND, DGND. Protocollo di IO digitale: - Downlink: 40 Mb/s. - Uplink: 160 Mb/s mediante due link. 3

4 Possibili scenari di Upgrade Luminosità di picco (10^34) Luminosità integrata (fb^-1) Start2481012141618 anni “2013” I tempi degli upgrade sono (al momento) determinati dai tempi previsti per l’upgrade della macchina e non dai tempi di realizzazione del nuovo rivelatore. 4 “2017, 2018” Luminosità di picco Luminosità integrata

5 I dettagli dipendono molto dalle condizioni di esercizio (temperatura e warm-up) I moduli dei Pixel sono stati irraggiati a due volte la dose nominale e sono risultati perfettamente funzionanti. B-Layer Task Force: Lifetime In all cases: integrated dose acceptable, even with margin of error, for 5 years, but not for 8. 5 Years R=5cm R=5cm 1.5 x dose R=3.5 cm Years Jens Weber Case shown: 2 ºC operation 30 day access Nom. + 50% Nominal flux

6 Simulazioni: LHC full luminosity 40 80 120 160 200 100 0 0200300400500 600 R [mm] Z [mm] 37 50.5 88.5 122.5 2.082.032.28 0.830.840.87 0.40 0.440.41 1.361.351.260.88 rates given in [10 6 pixel hits.module -1 s -1 ] [10 6 pixel hits.FE -1 s -1 ] FE-I3, 50μm×400μm. FE-I4 simul., 50μm×250μm. η=0.1η=0.2η=0.3η=0.4η=0.5η=0.6η=0.7η=0.8 η=0.9 η=1.0 η=1.2 η=1.5 η=2.0 η=2.5 η=3.0 η=3.5 1.401.311.32 2.012.032.142.17 0.81 0.820.84 0.420.43 Assumptions: 100kHz L1T, 336×80 50 x 250 pixels FE-I4 1.35 2.09 0.82 0.42 6

7 40 80 120 160 200 100 0 0200300400500 600 R [mm] Z [mm] 324 524 37/37 70 131 201 50.5 88.5 122.5 36.8935.7635.9736.4635.9433.2623.23 mean: 35 mean: 19.5 mean: 7.8 mean: 4.7 mean: 2.3 210 150 FE-I4, 50μm×250μm. FE-I4 simul., 50μm×250μm. FE-I4 Nigel, 50μm×250μm. FE-I4 sdtf 220908, 50×250μm 2. η=0η=0.1η=0.2η=0.3η=0.4η=0.5η=0.6η=0.7η=0.8 η=0.9 η=1.0 η=1.2 η=1.5 η=2.0 η=2.5 η=3.0 η=3.5 Simulazioni: 10×LHC (25ns bx) / sLHC rates given in [pixel hits.bx -1 cm -2 ] 7

8 40 80 120 160 200 100 0 0200300400500 600 r [mm] z [mm] 324 524 37/37 70 131 201 50.5 88.5 122.5 mean: 60 mean: 34 mean: 13.4 mean: 8.4 mean: 3.9 210 150 FE-I4, 50μm×250μm. FE-I4 simul., 50μm×250μm. FE-I4 Nigel, 50μm×250μm. FE-I4 sdtf 220908, 50×250μm 2. η=0η=0.1η=0.2η=0.3η=0.4η=0.5η=0.6η=0.7η=0.8 η=0.9 η=1.0 η=1.2 η=1.5 η=2.0 η=2.5 η=3.0 η=3.5 55.1038.6759.1560.1260.0258.7461.18 Simulazioni: 10×LHC (50ns bx) / sLHC rates given in [pixel hits.bx -1 cm -2 ] 8

9 Reasonable fit with: exp(1.34-0.57*R)+0.15-0.0053*R sLHC, 50ns bx / 400 events pileup Hits/mm 2 r [cm] Hits/mm 2 r [cm] sLHC, 25ns bx / 240 events pileup Reasonable fit with: exp(0.86-0.58*R)+0.088-0.0031*R sLHC (25ns)sLHC (50ns) Radius layer [mm][pix.bx -1.cm -2 ] 373560 50.519.534 7010.618.4 88.57.813.4 122.54.78.4 1314.78.3 1504.27.1 2012.54.4 2102.33.9 Simulazioni: Raggi diversi 9

10 L’occupanza di doppia colonna ed il numero di buffer di fine colonna implementati come nel FE-I3 non scalano bene con la potenza consumata e con l’aumento di occupanza. Tutti gli Hit vengono copiati ei buffer di fine colonna, ma solo < 1% vengono triggerati! L’idea è di memorizzare tutta l’informazione localmente nella regione che contiene i Pixel e di trasferire nei buffer di fine colonna solo i dati che sono stati triggerati. Memorizzare tutta l’informazione nei singoli Pixel non è possibile dato che un buffer per Pixel non sarebbe sufficiente e più di un buffer per Pixel non ci stanno. Pertanto l’idea è quella di raggruppare il maggior numero di Pixel in modo da formare “regioni locali” che possano condividere i singoli buffer in modo da ottimizzare la memoria necessaria. Occorre trovare un compromesso tra le dimensioni della “regione locale” e la complessità nell’implementare la logica necessaria ed il routing nella regione. EoC buffers double column FE-I3 50 µm 500 µm 2x2 (or 2x4) region CK & LV1 Output Data FE-I4 Necessità di una nuova architettura 10 LHC 3 x LHCsLHC

11 La tecnologia da 0.13 µm permette: chip più grandi, pixel più piccoli e maggiori velocità di lettura dei dati. Il nuovo chip di FE deve ridurre il materiale ed aumentare la frazione di area attiva. - Chip più grandi con wire-bond su di un lato solamente. FE-I3 ha 18 colonne x 160 righe di pixel di 50 µm x 400 µm organizzati in coppie di colonne in modo da condividere la logica digitale. Nel FE-I4 le dimensioni del pixel sono 50 µm x 250 µm, disposti in 80 colonne x 336 righe. La massima dimensione di un chip nella tecnologia CMOS8RF è di 19.5 mm x 21.0 mm. Un chip di dimensioni maggiori riduce il costo del bump-bonding a causa della necesità di prelevare, allineare e depositare un numero inferiore di circuiti integrati. Nel nuovo rivelatore a Pixel è possibile rinunciare all’MCC, dato che parte delle funzionalità ivi implementate saranno integrate nel circuito di Front End. Per sLHC la velocità di trasmissione sarà di 640 Mb/s, mentre per l’IBL di 160 Mb/s. Dimensioni e velocità di lettura 11

12 Si pensa di utilizzare il chip FE-I4 sia per l’IBL che per i due layer esterni del rivelatore a Pixel per sLHC. Il data rate è compatibile con sLHC @12-30 cm. Questo ci permette di focalizzarci sull’IBL ed utilizzare il progetto come passo intermedio verso sLHC. L’architettura finale del chip di Front-End sarà la stessa e solo il readout e la periferia del chip verranno cambiate per adattarsi alle esigenze specifiche di sLHC. 12 Radiu s (cm) IBL Bw (Mbit/s ) [Module] IBL Bw (Mbit/s) [Half Stave] sLHC [25 ns] Bw (Mbit/s) [Module] sLHC [25 ns] Bw (Mbit/s) [half stave] sLHC [50 ns] Bw (Mbit/s) [Module] sLHC [50 ns] Bw (Mbit/s) [half stave] 3.7 86129025838704316465 7 32852485528832 16 13221122123392 20 9615361482368 Moduli per IBL & sLHC

13 Pixel size50 x 250 µm 2 DC leakage current tolerance100nA Pixel array size80 x 336 Col x Row Normal pixel input capacitance range300-500fF Long pixel input capacitance range450-750fF In-time threshold with 20ns gate (400pF)4000e-e- Hit-Trigger association resolution25ns Sample pixel two-hit discrimination (time)400ns Single channel ENC sigma (400fF)300e Tuned threshold dispersion (max)100E Charge resolution4Bits ADC methodToT Operating voltage range1.2-1.5V Total analog supply current @400 fF10µA / pixel Radiation tolerance (specs met at this dose)200MRad Average Hit rate200MHz/cm 2 Trigger latency (max)3.2µs Single chip data output rate160Mb/s Maximum Trigger rate200kHz Total digital supply current @ 100 kHz10µA / pixel 13 Il nuovo B-Layer sarà a 3.7 cm dal fascio. L’occupanza salirà di un fattore 4 per unità di area. Le bande passanti dei link aumenteranno di un fattore 4 per unità di area. Il SEU (Single Event Upset) e la dose di irraggiamento avranno un’importanza maggiore. Il pixel avrà dimensioni lineari di 50 µm x 250 µm e la parte analogica del pixel occuperà circa il 50% dell’area. Le configurazioni potranno essere caricate a 40 MHz. FE-I4: Le specifiche

14 Transistor d’ingresso realizzato con un triple-well NMOS. Il secondo stadio usa un PMOS come input. È un preamplificatore di carica ottimizzato per low power, low noise e fast risetime. Il circuito di feedback è realizzato mediante due FET, CF è di 15fF, e c’è un circuito di compensazione della corrente di leackage attivo e differenziale. L’uscita del preamplificatore va ad un comparatore con una soglia globale regolabile nel singolo pixel basato su di un DAC a 5 bit. CC/CF2=5.8CF=17fF 4 bits 5 bits 12 bit configuration word per Pixel design by Abderrezak Mekkaoui FE-I4: la cella analogica 14

15 Nel FE-I3 il comparatore era usato per: - Segnalare la presenza di una particella (comp. edge), - Misurare il tempo di arrivo (leading edge), - Misurare la carica, ToT (comp. width). Nel FE-I4 invece: - Usiamo il comparatore per misurare il ToT. - Richiediamo un (ToT > 50:75 ns) per identificare una particella. - In questo caso si usa il leading edge come timestamp per l’intera regione. Questo implica un time-walk basso! - Usiamo il ToT di impulsi piccoli solo per informazioni di traccia, nei clusters di Pixels locali. - Si potrebbero usare i ToT piccoli come “noise hits” durante la calibrazione. 15 small ∆t big ∆t FE-I4: la regione digitale

16 Un framework formalmente corretto, in grado di simulare tutti gli aspetti legati alla realizzazione del chip è il prerequisito fondamentale per poter effettuare tutti i controlli necessari a produrre un circuito che rispetta le richieste. - A Bonn è stato sviluppato un simulatore scritto in C++ che permette di utilizzare dati provenienti dalle simulazioni di fisica. - La parte di Front-End analogico è descritta mediante Analog Verilog, quella digitale da un modello Verilog. I due diversi livelli di simulazione sono tra loro integrati per poter confrontare le varie opzioni disponibili. 0.1% 1% 10% LHC 1.6 % sLHC 4xLHC sLHC 0.22 % 16 Simulzioni dell’architettura 0.1% 1% 10%

17 17 Inefficienze in funzione del numero di Buffer. 2x2 Pixel Region4x2 Pixel region 10% 1% 0.1% BL@LHC 2 x LHC SLHC 10% 1% 0.1% 4x2 Pixel Region2x2 Pixel Region Larger region Faster Erase More Buffers Il numero di pixel raggruppati in una regione viene determinato in base alla simulazione ed ai constraint che derivano dal layout del blocco. Dimensionamento dei buffer 10%

18 Requirements: Ci serve un protollo seriale digitale. Dobbiamo concentrare dati provenienti da diversi chip. Dobbiamo gestire bandwidth molto diverse. Lo stesso link utilizzato per: Data + Configuration + Monitoring. Issues to be addressed: Bandwidth (minimizzazione, high link occupancy): Come trattare i problemi di bandwidth? Buffer overflow? Drop some data? SEU: Dobbiamo mantenere la sincronizzazione degli eventi (la perdita di alcuni dati non è un problema). Redundancy: Dobbiamo prevedere la possibilità di errori hardware. DC balancing: Serve? È safe in caso di SEU? Formato dei dati

19 Protocollo di trasmissione Per l’IBL dobbiamo mantenere la compatibilità con l’hardware attuale: 40 Mb/s in downlink e 160 Mb/s sull’Uplink. Clock e Dati separati su due lineee distinte. Per sLHC ci sono al momento contatti tra Pixel ed SCT per lo sviluppo di un protocollo comune che permetta di semplificare il readout dei due rivelatori. Questo è un campo dove sarebbe augurabile una maggiore integrazione anche tra ATLAS e CMS. Ci sono alcuni progetti che si prefiggono questo sia a livello di CERN che di INFN. Potrebbe portare ad un risparmio significativo ed ad una semplificazione notevole nel design dei sistemi di configurazione e readout dei rivelatori, ma è di MOLTO difficile realizzazione. Occorre far interagire persone di sezioni diverse dell’INFN e soprattutto appartenente a due esperimenti “competitor”.

20 FE-I4_proto1 collaboration Participating institutes: Bonn, CPPM, Genova, LBNL, Nikhef. Bonn: D. Arutinov, M.Barbero, T. Hemperek, M. Karagounis. CPPM: D. Fougeron, M. Menouni. Genova: R. Beccherle, G. Darbo. LBNL: R. Ely, M. Garcia-Sciveres, D. Gnani, A. Mekkaoui. Nikhef: R. Kluit, J.D. Schipper FE-I4-P1 LDO Regulator Charge Pump Current Reference DACs Control Block Capacitance Measurement 3mm 4mm 61x14 array SEU test IC 4-LVDS Rx/Tx ShuLDO +trist LVDS/LDO/10b-DAC

21 Stiamo lavorando ad uno sviluppo legato all’IBL. Abbiamo iniziato il disegno di una nuova architettura che dovrebbe essere compatibile con i requirement che vengono da sLHC. Abbiamo realizzato alcuni prototipi, funzionanti, con la nuova tecnologia (IBM 0.13 µm) che dimostrano la fattibilità del progetto. Possiamo realizzare una prima versione di questo chip nel 2009 ed utilizzarla nel nuovo B-Layer dei Pixel di ATLAS. Sarà “almost compatibile” con l’hardware attuale in modo da poter runnare con il rivelatore attuale Ci sono delle prospettive di lungo termine molto interessanti legate a possibili sinergie tra diversi rivelatori. Conclusioni