Il progetto FF-LYNX nasce dalla collaborazione tra la Sezione di Pisa dell’INFN e il Dipartimento di Ingegneria dell’Informazione dell’Università di Pisa e ha come obiettivi la definizione e la validazione di un protocollo per la distribuzione dei segnali di clock e trigger e di controllo e per l’acquisizione dei dati negli esperimenti di fisica delle alte energie e astrofisica spaziale e la sua implementazione in interfacce a bassa dissipazione di potenza e resistenti alla radiazioni progettate e realizzate in tecnologie CMOS commerciali.



I primi mesi di attività sono stati dedicati all’analisi dei possibili requisiti nei futuri esperimenti di Fisica delle Alte Energie (e.g.: “Upgrades” di LHC) e dei protocolli attualmente utilizzati (e.g.: in CMS e in ATLAS). Sono stati identificati alcuni requisiti di base nella prospettiva di una ottimizzazione del progetto dei sistemi di controllo e acquisizione:



R.1 la distribuzione dei segnali di timing e di trigger e dei segnali di controllo e l’acquisizione dei dati dovrebbero essere gestite dallo stesso protocollo e dagli stessi dispositivi;



R.2 il protocollo dovrebbe utilizzare “frames” indipendenti rispetto al tipo di dati e quindi essere compatibile con dati di natura diversa: (e.g.: dati di monitoraggio o di configurazione, dati generati da rivelatori di natura diversa, come rivelatori al Silicio a pixel o a strip o rivelatori a gas);



R.3 le interfacce che implementano il protocollo (i.e.: Trasmettitore TX e Ricevitore RX) dovranno essere compatibili con linee di trasmissione seriali ed elettriche da utilizzarsi per collegare l’elettronica di “Front-End” alle interfacce con i canali di trasmissione in fibra ottica che, dissipando un’elevata potenza, dovranno essere posizionate lontano dagli elementi attivi al fine di limitare l’impatto del sistema di raffreddamento sul “material budget”.



Le principali caratteristiche della prima versione del protocollo, disponibile già nel Maggio del 2009, sono descritte sinteticamente.



1. Integrazione della distribuzione dei segnali di timing, trigger e di controllo e dell’acquisizione dei dati



Due canali distinti “multiplexati” nel dominio del tempo vengono utilizzati per la trasmissione di Trigger, Frame Header e segnali di sincronizzazione (canale THS) e dei dati organizzati in “Frame” (FRM channel).



2. Flessibilità rispetto al “data rate”

Il protocollo e’ compatibile con diverse velocità di trasmissione (4F, 8F e 16F; F = frequenza del clock di riferimento).



3. Struttura generale dei “frame” dei dati

I dati sono organizzati in “frame” la cui struttura è indipendente dal tipo di dato trasmesso. Un “Frame Descriptor” iniziale specifica informazioni essenziali associate al frame (e.g.: la sua lunghezza) ed è seguito da una “Label” opzionale, dal Payload vero e proprio costituito da un numero variabile di parole da 16 bit (fino a 16) e da un campo opzionale per il “Cycle Redundancy Check” (CRC).



4. Robustezza delle informazioni critiche rispetto agli errori indotti da radiazione o rumore

Per Trigger, Frame Header e sequenze di sincronizzazione si utilizza una codifica robusta “custom” che consente di individuare la sequenza di interesse e ricostruire esattamente la sua temporizzazione anche in presenza di errori singoli e di individuare errori doppi. Per il Frame Descriptor è utilizzata una codifica di Hamming standard che consente di individuare e correggere gli errori singoli.



5. Compatibilità con linee di trasmissione seriali

Le interfacce TX e RX sono compatibili con link elettrici seriali “double-wire” (i.e.: clock e dati trasmessi su linee separate). Nel 2011 si prevede lo sviluppo di interfacce compatibili con link “single-wire” (i.e.: clock e dati codificati su una unica linea seriale) basate sull’introduzione di una codifica “8b/10b” sul canale FRM che consenta la ricostruzione del clock nei ricevitori.



6. Semplice interfacciamento con i dispositivi “host”

Le interface TX e RX sono equipaggiate con porte seriali e parallele (16 bit) per comunicare con i dispositivi “host”.



7. Compatibilità con topologie diverse dei sistemi di controllo e acquisizione

Il protocollo e le interfacce sono compatibili con topologie a stella e ad anello del sistema di controllo e acquisizione attraverso l’introduzione di moduli digitali addizionali: il modulo di concentrazione dati (DCM) e il modulo di gestione della ridondanza (RM). Nelle topologie a stella dati ingresso provenienti da diversi circuiti di Front-End vengono compressi nel modulo DCM in un unico “stream” seriale in uscita. Nelle topologie ad anello il modulo DCM concentra in ogni nodo dell’anello i dati generati localmente con quelli provenienti dai nodi precedenti, mentre il modulo RM gestisce la ridondanza (i.e.: l’esclusione dall’anello di eventuali nodi affetti da malfunzionamenti).



Modelli ad alto livello (System-C) delle interface TX and RX sono stati sviluppati al fine di validare il protocollo, inclusa la sua robustezza nei confronti degli errori di trasmissione, e di ottimizzare i suoi parametri attraverso l’introduzione di figure di merito (e.g.: Trigger Loss Rate, Packet Loss Rate, Packet Latency). Il simulatore è basato su una architettura modulare con moduli “client” e “server” comunicanti attraverso “sockets” TCP/IP. I moduli “client” generano i vettori di test e analizzano i risultati della simulazione, mentre i moduli “server” eseguono la simulazione vera e propria.. Il carico computazionale può essere ripartito tra processori operanti in parallelo come stazioni di lavoro Symmetric Multi-Processing (SMP) ad alte prestazioni o “grids” di processori (e.g.: la “grid” con 1500 processori installata presso l’INFN di Pisa). Nel Luglio 2009 si è completata la validazione della prima versione del protocollo con l’impiego vettori di test (i.e.: coordinate degli “hits” e carica rilasciata nei pixel o nelle strip) generati in simulazioni Geant4 relative a possibili geometrie proposte per gli “Upgrades” di CMS.



Sono stati sviluppati modelli VHDL delle interfacce TX and RX nelle tre configurazioni previste per la velocità di trasmissione (4F, 8F e 16F). I modelli sono stati funzionalmente validati in un “test bench” concepito come possible sistema di controllo e acquisizione dati per i moduli (16 circuiti di Front-End ciascuno) del rivelatore a pixel di CMS in vista dell’”Upgrade” di Fase I. La validazione delle interfacce si è completata con successo nel Luglio 2009.



La “roadmap” iniziale del progetto prevedeva per la seconda metà del 2009 il disegno del primo circuito di test contenente prototipi delle interfacce TX e RX realizzati sotto forma di macro-celle digitali resistenti alle radiazioni e a bassa dissipazione di potenza. I suggerimenti dei “referees” e le interazioni con i potenziali utilizzatori del protocollo e delle interfacce ci hanno spinto a modificare la “roadmap” prevista e a posporre la realizzazione del circuito di test al 2011. E’ stata invece introdotta una nuova attività come parte integrante del progetto: lo sviluppo di un dimostratore basato su una scheda di sviluppo commerciale equipaggiata con una dispositivo FPGA ad alte prestazioni (Altera Stratix III) ad alte prestazioni e connessa attraverso porte USB e G-Bit Ethernet con il PC Host. Tale sistema “real-time” consente di raggiungere nell’emulazione delle trasmissioni prestazioni sensibilmente superiori a quelle raggiungibili con simulazioni eseguite su processori commerciali. Il dimostratore rappresenta inoltre un test-bench ideale per la caratterizzazione di link fisici e prototipi di rivelatori. Il programma di analisi che viene eseguito sul PC “host” è lo stesso utilizzato nel simulatore ad alto livello e caratterizza il protocollo, le interfacce e il mezzo fisico di connessione rispetto alle stesse figure di merito. Lo sviluppo del dimostratore è iniziato nel mese di Maggio e si è completato in Ottobre 2010; il test di “link” basati su protocollo e interface FF-LYNX si è svolto nei mesi di Novembre e Dicembre.



Nel Febbraio 2011 è stato sottomesso il primo test-chip integrante le interfacce FF-LYNX trasmettitore e ricevitore alle tre diverse velocità, 4-8-16x rispetto al clock di riferimento. Il test-chip FF-TC1 integra inoltre FIFOs su cui sono state implementate tecniche di radiation-hardening al fine di proteggere il funzionamento del sistema da effetti di irraggiamento. Tecniche quali Tripla Ridondanza e Hamming Encoding sono state inoltre implementate. Nel test-chip sono stati integrati anche moduli per il supporto della fase di test sia funzionale che sotto irraggiamento. La validazione del chip è stata svolta con successo, grazie allo sviluppo di un ambiente di test customizzato, provando la corretta funzionalità delle interfacce anche sotto irraggiamento.



Le interazioni avute durante l’attività di definizione delle specifiche con gruppi diversi coinvolti nello sviluppo di rivelatori ed elettronica di Front-End per futuri esperimenti di HEP ha reso evidente la necessità di arricchire il protocollo FF-LYNX con nuove potenzialità. In particolare appare evidente che nei futuri esperimenti sarà necessario trasmettere dati provenienti dai Tracciatori al Silicio ai processori di trigger di livello 1 al fine di mantenere la frequenza di trigger a livelli compatibili con le bande passante dei canali di trasmissioni, con le capacità di calcolo dei processori di trigger di livello superiore e con le capacità di “storage” dei dati. Un protocollo che possa gestire la trasmissione di questi dati (“trigger” data) dovrà garantire latenze contenute e costanti, essere in grado di offrire le bande passanti richieste e assorbire, se necessario, picchi di dati senza perdere informazioni rilevanti dal punto di vista fisico. All’inizio di Maggio 2009 si è deciso di iniziare un’attività di analisi preliminare delle specifiche, in parallelo allo sviluppo della prima versione del protocollo, in vista dello sviluppo di una seconda versione da definire nella seconda metà dell’anno. La validazione della seconda versione del protocollo, iniziata negli ultimi mesi del 2009 si e' completata nel Febbraio del 2010. La principale innovazione si è tradotta nell’introduzione di “frame” a latenza fissa (FL frames) che vengono trasmessi con la massima priorità in ogni nodo della rete di acquisizione. Ciò garantisce la possibilità di trasmettere i dati per il processore di trigger con latenza contenuta e costante. E’ inoltre prevista una capacità di “buffering” che consente di assorbire picchi di dati. Tra i mesi di Ottobre e Dicembre sono stati sviluppati e validati con successo i modelli ad alto livello e VHDL delle interfacce TX e RX che implementano la nuova versione del protocollo e la cui implementazione nel dimostratore FPGA e’ iniziata nel Gennaio 2010



Il progetto FF-LYNX ha suscitato sin dall’inizio grande interesse nelle comunità di CMS e ATLAS, in particolare nei gruppi già impegnati negli studi preliminari sui rivelatori al Silicio e sui circuiti di Front-End in vista dei previsti “upgrades” di LHC. Con questi gruppi (INFN-PI, INFN-GE, CERN, EPFL, PSI, Imperial College) abbiamo collaborato intensamente durante la fase iniziale di analisi dei requisiti e definizione delle specifiche.



In particolare il Dipartimento di Fisica (J. Incandela, R. Rossin, S.A. Koay, N.McCall) dell’Università della California a Santa Barbara (UCSB) con il quale un membro del nostro gruppo (G.Magazzù) aveva avuto modo di collaborare in passato per lo sviluppo del Tracciatore di CMS ha deciso di collaborare con noi nello sviluppo di un ambiente di simulazione integrato che consenta di validare protocollo e interfacce utilizzando stimoli generati in simulazioni Geant4 e che includa modelli dei circuiti di Front-End e sullo sviluppo di dimostratori FPGA utilizzabili come “test-bench” per prototipi di moduli di rivelatori al Silicio. Nella seconda metà dell’anno si è deciso di formalizzare la collaborazione e UCSB ha deciso di investirvi significative risorse. Sono state finanziate due borse di studio semestrali presso il CERN per giovani neolaureati delle quali usufruiscono a partire dal mese di Febbraio 2010 Giovanni Bianchi e Claudio Tongiani, che in Ottobre 2009 hanno conseguito la Laurea Specialistica in Ingegneria Elettronica e Ingegneria Informatica con attività di tesi svolta nel quadro del progetto FF-LYNX e una borsa di studio di durata biennale per un dottorando del Dipartimento di Ingegneria dell’Informazione dell’Università di Pisa (Nico Costantino) che ha svolto parte della sua attività di dottorato presso il CERN e parte presso UCSB.