Qualche numero da SuperB

Qualche numero da SuperB

• L=10³⁶ cm-2 s-1, =100 nb (sovrastimata)

• Bunch separation =100ns-1 us

• #evt/bunch =0.01 -0.1

• # trk/evt=10

• L0 con MAPS:

– R=0.5 cm, L=10 cm, pitch=35x35 um2 – ~2.5 Mpixel. ~ 350 chips da 64x128.

• # trk/bunch/chip =10^-4 - 10^-3

• Un chip e’ colpito da una traccia ogni 10⁴ – 10³ bunch crossing, ma gli hit di noise (~0.3/chip/bunch), e

quelli di background (quanti?) arrivano ogni bunch.

L’approccio piu’ facile

• Se ad ogni bunch crossing (BCO) riesco a leggere tutto il chip, gestire il timestamp non sembra

problematico (reset ogni BCO e tutti gli hit letti hanno stesso BCO). Assumo che ci sia

sparsificazione!

– Molteplicita’ dei cluster 3x3? Forse meno…

– Occupancy da noise in 100 ns ~ 10^-4 (threshold 1/4 MIP) -> 0.3 pixel/bunch/chip

– Background?

• Supponendo di avere un clock a 100 MHz

– bunch separation: 100 ns -> siamo marginali.

– bunch separation: 1 us -> accettabile?

Alternative

• Esistono gia’ architetture di readout che non

potendo leggere tutto il chip ad ogni bunch crossing prevedono una logica (stile FPIX di BTEV o altro) che gestisca hit di piu’ BCO contemporaneamente presenti sul chip.

– In BTEV questo e’ necessario (un chip vede una traccia, o piu’, ogni 4 bunch crossing)

• Nel caso di una SuperB, dove ogni chip vede un evento ogni 10⁴ bunches (100 ns apart), e’ proprio necessaria una risoluzione sul timestamp con la stessa granularita’ del bunch crossing o e’

accettabile una granularita’ del timestamp di N bunch crossing?

Hit generati @ BCO

Timestamp

Readout bus

Bunch Crossing

BCO+1

10 9 BCO+1 8 BCO 1 BCO

Hit Timestamp

• Posso pensare ad un’architettura semplificata rispetto a FPIX (quindi forse piu’ facilmente realizzabile sulle aree piccole dei pixel MAPS) che scriva sul chip solo il timestamp del bunch corrente. L’associazione hit-timestamp avviene solo nel momento in cui l’hit viene portato fuori dal chip:

• hit di fisica, generati nello stesso bunch crossing, possono avere timestamp di N bunch crossing consecutivi

• N dipende dall’occupancy per chip e dalla frequenza del readout clock.

• Quale sarebbe la situazione per ILC

• Quale granularita’ di timestamp sarebbe

sufficiente?