Stato lavori Superpix1 e ApselVI Fabio e Filippo 1 “... siam mica qui a rubar le noccioline a CHIP e CIOP!”

Superpix1 2 -matrice pronta (fino al LEF), ma occorre reiterazione per gli aggiornamenti che verranno da Alessia -da fare modelli funzionali per le parti analogiche e simulazioni funzionali “3D” -simulazioni con metodo Filippo, senza e con netlist Verilog matrice -P&R, validazioni finali ApselVI -simulazione con metodo Filippo senza netlist matrice, ultima release pronta ma ora non posso  cercheremo di costruire un set di condizioni che riteniamo esaustive da simulare prima della sottomissione e ogni volta che si modifica qualcosa -ricevuta la parte di Luigi, creata doppia coppia (quartina) di pixel, una coppia “in salita” e una “in discesa”, per implementare il serpentone dello shift register -simulazione mista della quartina in corso -poi costruzione colonna, gruppo da 16, semimatrici, matrice completa -poi simulazioni Verilog della matrice completa -poi simulazioni m. F. con netlist matrice -P&R, validazioni finali

3 Superpix1: COPPIA

4 ApselVI: QUARTINA

Riassunto simulazioni metodo Filippo 5 Prima di tutto, per focalizzare: si tratta della simulazione della logica del blocco di readout descritta in VHDL insieme al modello funzionale della matrice. Quando il tutto verra’ considerato funzionante, seguira’ una sintesi logica con la creazione dell’implementazione fisica insieme alle fasi di Place & Route. Scopo di questo sforzo? Fare i muscoli? NO, “siamo seri”, ha detto B. a B. SCOPO #0: essere il piu’ possibile sicuri che il chip funzioni nelle piu’ disparate situazioni, dalla piu’ banale “niente scatta niente deve uscire” alle occupancy piu’ alte in cui piu’ eventi vengono internamente cancellati per poter star dietro alla trigger latency e al datapush. I dati in uscita non devono essere corrotti e quelli mancanti devono essere adeguatamente flaggati. SCOPO #0.1: cercare di stabilire quali tipi di stimoli (hit e trigger nel tempo, readout clock e timestamp clock ratio & freq) coprono al meglio la funzionalita’ del circuito SCOPO #0.2: usare questo set di stimoli per validare il circuito ad ogni modifica Il set di stimoli e’ un insieme di file di configurazione (testbench.fdo) ognuno dei quali definisce tutte le condizioni di partenza e di svolgimento di una simulazione. Durante ogni simulazione vengono generati dei file di expected data e di output data, ed un apposito programma da lanciare alla fine della simulazione esegue un completo check expected vs output segnalando gli eventuali mismatch. E’ possibile usare degli script per far eseguire piu’ testbench consecutivi.

Riassunto simulazioni metodo Filippo 6 Scelta del funzionamento datapush o triggered. Possibilita’ di configurare il chip tramite operazioni i2c. Super set di waveform raggruppate per funzionalita’, possibile controllare ogni parte del circuito. Generazione hit: -a burst: hit rate, durata e periodo di ripetizione programmabili -continuo: hit rate programmabile -rate programmabile: usato da 1 a 100 MHz/mm 2 -full-noise: tutti i pixel si accendono insieme -modo calibrazione: devo ancora leggermelo e capirlo Readclock (matrix readout clock), fastclock (output data clock) e timestamp clock programmabili: importante e’ fastclock/readclock (lettura matrice e svuotamento barrel dei dati) e hit_rate/timestamp clock che definisce il numero di hit per evento (timestamp period) La simulazione e’ inizialmente fatta in modo funzionale, nessun ritardo intrinseco dei circuiti, solo clock driven. In un secondo tempo al posto del modello funzionale semplificato della matrice verra’ sostituita la netlist Verilog del circuito vero con i ritardi molto vicini a quelli dell’implementazione fisica: in questo modo si controllano le connessioni matrice- readout e il rispetto dei timing. Alla fine si puo’ sostituire il modello funzionale del readout con la netlist del circuito fisico finale, completo dei ritardi.

Riassunto simulazioni metodo Filippo 7 Il frame messo su da Filippo... devo ancora capirlo bene, ma mi dice che nelle sue intenzioni era nato per essere generale e quindi in qualche modo customizzabile per altri progetti. Lui si’ che e’ un programmatore moderno, io ho avuto l’imprinting dell’assembler e sono fregato. Quando si sono riprodotti in lab alcuni risultati visti al beamtest a soglie basse, sono nate le richieste a Filippo di rimettere mano al suo circuito per farlo funzionare “correttamente” in “qualsiasi” condizione. Ho risposto al grido di aiuto di Filippo e alla fine ne e’ uscito un circuito che e’ in grado di segnalare nel flusso dati i momenti in cui ci sono stati problemi, permettendo la corretta assegnazione degli hit al proprio timestamp e la segnalazione dei timestamp cancellati o parzialmente corrotti: e’ possibile in analisi selezionare eventi puliti anche in condizioni proibitive e sfavorevoli (p.es. a basse soglie con alto hit rate). Memore dello sforzo che a suo tempo (sono quasi 20 anni, sigh!) feci per le simulazioni dell’AToM di Babar, ho sfinito Filippo fino a che non ha implementato un sistema simile nella filosofia dei check tra dati aspettati e dati usciti. Ora avrei da mettermi a capire e usare l’ultima release, ma e’ ripartito il lavoro insieme a Luigi e Alessia, ma prima o poi...

Riassunto simulazioni metodo Filippo 8 Manca qualcosa? Vediamo se sara’ possibile implementare lo scatto dei pixel secondo pattern fissati. In passato, sullo storico Apsel4D, abbiamo visto che particolari pattern di scatto andavano a creare condizioni particolari per la logica e i barrel, condizioni non ottenibili in modo immediato con pattern casuali. Non e’ detto che questo sia ancora valido per questi chip, ma potrebbe esserlo. Altra cosa che manca sono due teste, 4 mani e due corpi, ma ci siamo attrezzando.