From paola.giannetti@pi.infn.it Mon Sep 18 15:07:21 2006 Date: Mon, 18 Sep 2006 14:42:49 +0200 From: Paola Giannetti To: Mauro Villa Cc: Livio Lanceri , Luciano Bosisio , stefano.bettarini@pi.infn.it, Francesco Forti , giuliana rizzo , Valerio Re , Manghisoni Massimo Subject: Re: latenza e # di linee di outputs Be', per fortuna non e' del tutto vero questo, altrimenti applicazioni aggressive come LHC o SLHC non sarebbero immaginabili senza portare la AM a frequenze di funzionamento allucinanti. Considerando che le AM sono tante e lavorano in parallelo su eventi diversi, c'e' vantaggio ad avere un readout che va a (50 MHz x N di eventi storabili). Nell'ipotesi che noi si lavori con 4 bit di Bunch crossing e 16 AM, il readout piu' vantaggioso sarebbe 50 MHz x 16. Allego una slide esplicativa per una possibile applicazione ad SLHC che per l'appunto verra' presentata a Valencia la prossima settimana da Fabrizio Palla. Il readout provvede N eventi in pasto a N AMs che si caricano gli eventi in parallelo ciascuna a 50 MHz ora, 100 MHz con il prossimo prototipo. Tuttavia l'argomento che noi possiamo andare piu' piano e' sicuramente valido, per vari motivi. Le Maps non sono certo per SLHC, i tempi di risposta del rivelatore stesso sono lenti.... Usare 3 linee di output invece di 6 puo' essere giustificato dal fatto che le finanze sono scarse a GRV e che semplicemente comprare cio' che esiste e' forse piu' economico/veloce (anche se andrebbero consultate le offerte di CArdoso per accertarsi su questo punto) .... Insomma non credo che il punto veramente qualificante di SLIM5 sia la velocita' di readout del rivelatore. Altre applicazioni specifiche si possono cimentare in questo campo. Ciao Paola Mauro Villa wrote: > Ciao a tutti, > > Ho due piccole osservazioni e un nuovo conto: > - come risulta dai conti della Paola con 6 linee di uscita dall'FSSR2 si e' > gia' vicini al limite di clock della AM (20/25 ns rispetto ai 28.6 ns > necessari per ogni hit); > - il punto chiave e' che nel conto si e' considerato solo 1 chip FSSR, mentre > su UNA LINEA dati verso l'AM devono transitare tutte le hit di un ibrido (3 > FSSR2) piu' un time stamp per ogni evento. In sostanza un ibrido equipaggiato > on 3 chip letti su 6 linee ognuno fornisce le hit ad un rate massimo di una > hit ogni 9.5 ns. Questo rate (105 MHz) non e' gestibile ne' dalla EDRO (dove > vorremmo lavorare a 40 MHz) ne' dalla AM (max 50MHz). > > Provo a fare un conto dettagliato con queste assunzioni: > Ibrido con 3 chip letti con N linee, 24 bits/hit > Clock di lettura a 140 MHz (1 bit) > BCO clock a 2.52 MHz > ( da rivedere in quanto sembra troppo veloce per le MAPS) > Clock EDRO e AM a 40 MHz. > > Il rate di HIT in uscita dall'ibrido con N linee e' dato da: > 140 MHz * (N/24)*3 = 17.5 MHz*N > Il rate di Hit e' quindi: > 17.5 MHz per N=1 - gestibile da EDRO+AM > 35 MHz per N=2 - gestibile da EDRO+AM (vicino al limite di 40 MHz) > 70 MHz per N=4 - NON gestibile > 105 MHz per N=6 - NON gestibile > > Concludendo il conto: N=1 o N=2 sono gestibili dalla EDRO+AM, c'e' abbastanza > spazio per aggiungere il time stamp ad ogni evento. (N=3 non e' previsto nel > FSSR). N=4 o N=6 non risultano gestibili: il sistema EDRO+AM risulterebbe il > collo di bottiglia del sistema. > > Vediamo ora quante linee di I/O deve portare l'ibrido nuovo in funzione di N: > Nell'ibrido vecchio (6 Chip FSSR2 letti a 6 linee) era stato fatto questo > conto: > Ogni chip era letto con N=6 linee di I/O + altre 3 linee di controllo; vi > erano altre 7 linee di I/O comuni a tutti i chip per un totale di (6*(N+3)+7) > = 61; 18 di queste non erano collegate e quelle rimanenti (7) per arrivare a > 50 portavano le alimentazioni. (Su questo punto ho un dubbio: le linee di I/O > sono differenziali, mentre le alimentazioni no: come e' possibile arrivare a > 50 linee sul connettore??? - ) > Ripetendo il conto per il caso di 3 chip FSSR2: > Il numero di linee differenziali è (3*(N+3)+7) cioe': > 19 per N=1 -> 38 linee di I/o singolo + 12 alim. su un connettore da 50 > 21 per N=2 -> 42 linee di I/o sing, + 6 alim. su un connettore da 50 > 27 per N=4 -> 54 linee di I/o sing, > 33 per N=6 -> 66 linee di I/o > > A me sembra che N=2 linee di I/O per ogni FSSR sia piu' che sufficiente per i > nostri scopi; siamo gia' vicini al limite del nostro sistema. > > Performances di un sistema con N=2 linee di uscita sul FSSR2 e il BCO clock a > 2.52 MHz: > - processiamo le hit ad un rate massimo di 35 MHz; > - ogni "Evento" e' caratterizzato da un time stamp con la frequenza del BCO > clock (2.52 MHz); > - ad ogni BCO clock abbiamo la capacita' di processare 35 MHz/2.52 MHz = 13.9 > Hit in media per ogni ibrido (o se preferite 4.6 Hit/Chip FSSR2); > > Visto che non credo avremo 14 tracce su ogni ibrido ad ogni evento e il rate > di eventi dovrebbe essere inferiore ai 2.52 MHz, mi sembra inutile spingere > le performance del sistema oltre quello che si puo' ottenere con N=2 linee di > lettura sui chip FSSR2. > Che ne pensate? > > Ciao, > Mauro > > > > > > > > > > > On Thursday 14 September 2006 23:37, Paola Giannetti wrote: > >>Cari tutti, >>alcuni dati (da confrontare con quello che avete capito voi, per favore >>controllate) per giudicare se ci possiamo permettere di usare meno di 6 >>linee di outputs: >> >>mi sembra di capire che la lettura seriale veloce va al massimo a 140 >>MHz -> ~1 bit ogni 7,15 ns. >> >>Se si usano 6 linee di output per leggere una parola di 24 bits, >>occorrono 4 cicli e quindi ~28,6 ns che e' leggeremente piu' lento >>della memoria associativa che sulla carta puo' funzionare fino a 50 MHz >>(un hit ogni 20 ns) ma in CDF e' stata testata ampiamente solo a 40 MHz >>(un hit ogni 25 ns). >> >>Se si usano 3 linee di output invece di 6, per leggere un hit occorrono >>il doppio di cicli di clock, quindi ~57 ns/hit. >> >>Se si usa 1 sola linea di output occorrono 24 cicli di clocks, ~171 >>ns/hit. >> >>Il tempo di latenza e' quindi dominato dalla lettura del rivelatore, e >>qualcuno si puo' chiedere perche' si sia usato un readout ~6 piu' lento >>della AM, ma tuttavia tutto funziona anche usando una sola linea di >>readout per chip. Forse la dimostrazione di fattibilita' del sistema non >>e' inficiata dal fatto di andare piano nel readout. Se tutto funziona, >>possono credere che e' possibile usare un output piu' parallelo ed >>andare piu' forte.... >> >>Non so, sollevo la questione perche' penso piu' si restringe il campo >>delle variabili, piu' abbiamo facilita' di convergere presto. >>Pensate che potremmo lavorare con meno di 6 linee di output per chip? Se >>tutti sono daccordo, rilasciare questa richiesta favorirebbe l'uso del >>sistema vecchio che sembra fortemente preferito (se comunque riordinano >>il PCB dell'ibrido io sarei comunque favorevole ad usare connettori piu' >>affidabili in modo da andare direttamente alla vecchia PMC se possibile, >>senza passare dal patch panel) >> >>Ciao >> Paola > > [ Part 2, Application/VND.MS-POWERPOINT 135KB. ] [ Unable to print this part. ]