In questa session discutiamo di quegli aspetti che riguardano la zona DAQ e readout, ovvero l'interazione della RDO con il chip ALCOR e l'elettronica di front-end.
Visti più volte in test laboratorio e su test beam.
Bisogna capire definitivamente se l'origine è lato FPGA o lato ALCOR.
Se lato ALCOR, va fatto fix prima della prossima submission.
Se lato FPGA, meglio, capiamo e aggiustiamo.
Di base serve che qualcuno si prenda in carico della cosa.
In fase preparazione test beam ci eravamo messi a guardare la cosa sia a Bologna che a Torino. Poi si è fermato tutto, ma il problema è rimasto.
=== presentazione di Giulio ===
- fare prove bombardando di SOFT reset il chip dopo enable, per evitare incremento frame counter
- tempi morti?
--> stabilito che sono necessarie modifiche alla logica digitale di ALCOR
devono essere scritte parole di header/trailer ogni SOFT reset per stare dietro all'orbita
--> come facciamo HARD RESET? --> segnale RESET alto per 32 colpi clock?
--> come facciamo START OF RUN?
esattamente la stessa cosa che fa il SOFT reset
in più resettta il FRAME COUNTER ed eventuali altre cose non di configura
--> come facciamo START OF ORBIT?
reset dei coarse counter.
chiusura del frame precedente.
apertura nuovo frame
Partendo da un'email di Giulio, che riporto sotto ed è stato il trigger per questa riunione.
[caro amico ti scrivo, così mi distraggo un po']
Qui c'è da discutere per definire quali segnali ci servono per fare sunzionare, sincronizzare, eccetera tutta l'elettronica ad un collider.
- che facciamo con il segnale di clock? --> banale
- che facciamo con il segnale di reset?
- che facciamo con il segnale di test pulse?
- abbiamo altri segnali che vanno ad ALCOR? --> non mi pare
- ci servono altri segnali da mandare ad ALCOR? --> speriamo di no
"ti scrivo perchè vorrei cambiare il meccanismo di reset del frame
counter. Come si è visto nei test beam il reset dei contatori al momento
non resetta il frame counter. Se si vuole agire in quel senso bisogna
capire un paio di cose.
Caso 1. Il frame counter si resetta quando non ci sono dati pendenti in
nessuna parte del chip. In questo caso si resetta il frame, si chiude il
frame precedente con il trailer e si inizia il nuovo frame senza problemi
Caso 2. Il frame counter si resetta quando ci sono ancora dei dati da
processare nei pixel o nella fifo di ingresso del fine colonna. In
questo caso per essere il più puliti possibili si dovrebbe cancellare
tutti questi dati pendenti per evitare che finiscano in un frame
sbagliato. Oppure li si lascia come sono, ma potrebbero finire nel nuovo
frame anche se erano stati generati in quello precedente.
Quindi la domanda è, questo reset verrebbe inviato durante la presa dati
o solo quando il tutto è in pausa e non ci sono dati?"
Board Level Shielding (BLS)
Reduce, Limit, and Control EMI
meglio sulla RDO (FGPA e altra roba EMI) che su ALCOR.
compatibile con cooling ad aria?
In questa session discutiamo di quegli aspetti che riguardano la zona sensore SiPM e la sua interazione con il chip ALCOR e l'elettronica di front-end.
Farebbe comodo / serve una versione della FEB che permetta di mandare il bias ai SiPM per fare test di powering / annealing in versione finale.
Sarebbe praticamente la FEB finale, senza ALCOR, ma con tutto il resto:
- circuito RC per ingresso ALCOR (se serve, vedi dopo)
- diodi per annealing
- piste che portano Vbias e GND ai SiPM
Magari potrebbe essere simpatico che su questa FEB ci siano un paio di connettori RF (LEMO, SMA) per accedere ai segnali che andrebbero in ingresso al ALCOR. Così vediamo che stiamo facendo su oscilloscopio.