Data rates for FE-I4

annuncio pubblicitario
Pixel: Elettronica di
Front End
Roberto Beccherle, INFN - Genova
Incontro ATLAS e CMS per l'Upgrade a SLHC, Sestri Levante,
13 – 14 Novembre 2008
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
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 disaccoppiamento, 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
Possibili scenari di Upgrade
Luminosità di picco (10^34)
Luminosità integrata (fb^-1)
“2017, 2018”
“2013”
Luminosità di picco
Luminosità integrata
Start
2
4
8
10
12
14
16
18 anni
I tempi degli upgrade sono (al momento) determinati dai tempi previsti per
l’upgrade della macchina e non dai tempi di realizzazione del nuovo
4
rivelatore.
B-Layer Task Force: Lifetime
• In all cases: integrated dose acceptable, even with margin of error, for 5 years, but not for 8.
Nominal flux
Nom. + 50%
R=5cm
R=5cm 1.5 x dose
R=3.5 cm
Jens Weber
Years
Years
• 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.
5
Simulazioni: LHC full luminosity
R [mm]
η=0.1
200
η=0.2
η=0.3
η=0.4
η=0.5
η=0.6
η=0.7
η=0.8
η=1.0
η=0.9
η=1.2
160
122.5 0.43
120
88.5
0.43
0.40
0.40
0.42
0.44
0.42
FE-I3, 50μm×400μm.
FE-I4 simul., 50μm×250μm.
[106
rates given in
pixel hits.module-1s-1]
[106 pixel hits.FE-1s-1]
0.41
η=1.5
0.81
0.81
0.82
0.84
0.82
0.83
0.84
Assumptions:
• 100kHz L1T,
• 336×80 50 x 250 pixels FE-I4
0.87
80
η=2.0
2.17
2.14
2.03
2.01
40 1.40
1.31
1.36
1.35
50.5
37
2.09
1.35
2.08
2.03
2.28
1.32
1.26
0.88
η=2.5
η=3.0
η=3.5
Z [mm]
0
0
100
200
300
6
400
500
600
Simulazioni: 10×LHC (25ns bx) / sLHC
R [mm]
mean: 2.3
210
201η=0
200
η=0.1
η=0.2
η=0.3
η=0.4
η=0.5
η=0.6
η=0.7
η=0.8
η=1.0
η=0.9
rates given in
[pixel hits.bx-1cm-2]
160
η=1.2
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μm2.
150
131
122.5
120
η=1.5
mean: 4.7
mean: 7.8
88.5
80
η=2.0
70
mean: 19.5
50.5
40
36.89
37/37
35.76
35.97
36.46
35.94
33.26
23.23
η=2.5
η=3.0
mean: 35
η=3.5
Z [mm]
0
0
100
200
300
7
324
400
500
524
600
Simulazioni: 10×LHC (50ns bx) / sLHC
r [mm]
mean: 3.9
210
201η=0
200
η=0.1
η=0.2
η=0.3
η=0.4
η=0.5
η=0.6
η=0.7
η=0.8
η=1.0
η=0.9
rates given in
[pixel hits.bx-1cm-2]
160
η=1.2
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μm2.
150
131
122.5
120
η=1.5
mean: 8.4
mean: 13.4
88.5
80
η=2.0
70
mean: 34
50.5
40 61.18
37/37
58.74
60.02
60.12
59.15
55.10
38.67
η=2.5
η=3.0
mean: 60
η=3.5
0
0
100
200
300
8
324
400
z [mm]
500
524
600
sLHC, 25ns bx / 240 events pileup
Hits/mm2
Hits/mm2
Simulazioni: Raggi diversi
sLHC, 50ns bx / 400 events pileup
Reasonable fit with:
exp(1.34-0.57*R)+0.15-0.0053*R
Reasonable fit with:
exp(0.86-0.58*R)+0.088-0.0031*R
r [cm]
sLHC (25ns) sLHC (50ns)
Radius layer [mm] [pix.bx-1.cm-2] [pix.bx-1.cm-2]
37
35
60
50.5
19.5
34
70
10.6
18.4
88.5
7.8
13.4
122.5
4.7
8.4
131
4.7
8.3
150
4.2
7.1
201
2.5
4.4
210
2.3
3.9
r [cm]
9
•
•
FE-I3
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.
LHC
•
double
column
EoC buffers
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.
3 x LHC
•
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!
sLHC
•
Necessità di una nuova architettura
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.
500 µm
FE-I4
50 µm
2x2 (or 2x4)
region
CK & LV1
Output Data
Occorre trovare un compromesso tra le dimensioni della “regione
locale” e la complessità nell’implementare la logica necessaria ed il routing nella regione.
10
Dimensioni e velocità di lettura
•
•
-
•
•
•
•
•
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.
11
Moduli per IBL & sLHC
•
•
•
•
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.
sLHC [25
ns]
Bw (Mbit/s)
sLHC [25 ns]
Bw
(Mbit/s)
sLHC [50
ns]
Bw (Mbit/s)
sLHC [50
ns]
Bw (Mbit/s)
[Module]
[half stave]
[Module]
[half stave]
258
3870
431
6465
7
328
5248
552
8832
16
132
2112
212
3392
20
96
1536
148
2368
Radiu
s
(cm)
3.7
IBL Bw
(Mbit/s
)
IBL Bw
(Mbit/s)
[Module]
[Half
Stave]
86
1290
12
FE-I4: Le specifiche
• Il nuovo B-Layer sarà a 3.7 cm
Pixel size
dal fascio.
• L’occupanza salirà di un fattore 4
DC leakage current tolerance
Pixel array size
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.
Normal pixel input capacitance range
Long pixel input capacitance range
In-time threshold with 20ns gate (400pF)
Hit-Trigger association resolution
Sample pixel two-hit discrimination (time)
Single channel ENC sigma (400fF)
Tuned threshold dispersion (max)
Charge resolution
ADC method
Operating voltage range
Total analog supply current @400 fF
Radiation tolerance (specs met at this
dose)
Average Hit rate
Trigger latency (max)
Single chip data output rate
13
Maximum Trigger
rate
50 x
250
100
80 x
336
300-500
450-750
4000
25
400
300
100
4
ToT
1.2-1.5
10
200
µm2
200
3.2
160
200
MHz/cm2
µs
Mb/s
kHz
nA
Col x Row
fF
fF
ens
ns
e
E
Bits
V
µA / pixel
MRad
FE-I4: la cella analogica
4 bits
5 bits
12 bit
configuration
word per Pixel
design by
Abderrezak
Mekkaoui
CF=17fF
•
•
•
•
CC/CF2=5.8
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.
14
FE-I4: la regione digitale
•
Nel FE-I3 il comparatore era usato per:
small ∆t
-
Segnalare la presenza di una particella (comp. edge),
big ∆t
-
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
•
Simulzioni dell’architettura
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.
10%
10%
1.6 %
sLHC
sLHC
0.22 %
1%
4xLHC
0.1%
LHC
16
1%
4xLHC
0.1%
Dimensionamento dei buffer
10%
10%
2x2
2x2Pixel
PixelRegion
Region
1%
4x2
4x2Pixel
PixelRegion
region
1%
SLHC
0.1%
0.1%
2 x LHC
BL@LHC
10%
•
Inefficienze in funzione del numero di Buffer.
Larger region
More Buffers
Faster Erase
17
Il numero di pixel raggruppati in
una regione viene determinato
in base alla simulazione ed ai
constraint che derivano dal
layout del blocco.
Formato dei dati
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?
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”.
FE-I4_proto1 collaboration
FE-I4-P1
• Participating
institutes:
3mm
61x14 array
Charge
Pump
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
Capacitance
Measurement
Control Block
LDO
Regulator
DACs
4mm
Current
Reference
4-LVDS Rx/Tx
SEU test IC
ShuLDO+trist
LVDS/LDO/10b-DAC
Conclusioni
•
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.
Scarica