(Riunione settimanale di avanzamento progetto)
Presenti: Carlo, Giacomo (in collegamento telefonico), Nanni, Paolo Mo., Roberto.
Nel meeting dell'elettronica Kevin ha annunciato un ritardo di almeno 2 mesi nella sottomissione del FE-I. Abbiamo discusso 2 possibili alternative per la chiusura del disegno:
Si è deciso per la prima soluzione. Ciò implica terminare la simulazione entro il 3 luglio e quindi eseguire il layout e le verifiche nei successivi 15 giorni.
Nanni e Roberto hanno fatto visita Kostas e hanno ricevuto l'assicurazione del completamento della SRAM in un paio di giorni. Kostas ci trasmetterà il data base completo del disegno includendo Schematics, Layout (con verifica DRC e LVS), Abstract e LEF. Roberto ha detto che a Bonn sarebbero interessati ad inserire nell'MCC alcune funzionalità aggiuntive come un blocco con il DORIC, la misura di temperatura, smart power. Si è deciso che il presente MCC verrà sottomesso nella configurazione attualmente definita, ma c'è interesse e disponibilità a una possibile futura versione che implementi alcune delle aggiunte in discussione.
Roberto e Paolo Mo. trovano che una debolezza dell'Event Building è data dal controllo dei LV1 ricevuti dai FE che non risulta essere molto robusta. Infatti se un FE riceve un LV1 spurio, l'MCC non è in grado di accorgersi della situazione poiché il controllo di consistenza tra i vari FE è fatto sul L1ID e questo è in tale situazione lo stesso. Un controllo del BCID darebbe maggior garanzia sulla correttezza degli eventi. Roberto chiederà a Kevin se reputa possibile una modifica dei FE in modo che venga trasmesso il BCID invece del L1ID con i dati dei FE. Un altra debolezza dell'Event Builder è legata ad un possibile FE che non invii eventi e quindi la ScoreBoard (la ScoreBoard è una tabella che tiene conto quanti eventi sono memorizzati in ciascuna ReceiverFIFO) si trova con una locazione vuota. In questo caso l'Event Bulder si blocca aspettando i dati per quel FE. Identificare quale FE non mandi dati si può fare solo abilitando in successione un sottoinsieme di FE e provando ad acquisire eventi. Un metodo per semplificare il debugging sarebbe l'utilizzo di un registro in cui copiare '0' se la corrispondente locazione della Scoreboard è '= 0' o '1' se è ' 0' . In questo modo l'identificazione del FE difettoso è immediata leggendo il pattern di tale registro in caso di blocco nella trasmissione degli eventi da parte dell'MCC.
Carlo e Paolo Mo. stanno continuando le simulazioni del chip, per ora sempre a livello behavioural. A questo stadio del disegno questa è la parte più pesante e dove si dovranno concentrare gli sforzi, in particolar modo nelle prossime 2 settimane.
Giacomo non era riuscito a completare l'abstract della Delay line prima di partire da Genova (vi era ancora un errore su un pin di input). Lo completerà da Bonn la prossima settimana. Nanni ha generato la sintesi dell'albero del clock ottenedo un albero ad 8 livelli con 128 E_Inv8 che pilotano i 1940 FF del core del chip. Il risultato sembra ragionevole e da uno skew di circa 200 ps (Worst Case Commerciale - WCOM).
Roberto utilizzerà tali parametri per una sintesi più precisa del chip completo. Nanni e Rusty hanno definito un nuovo layout (rispetto a quanto proposto a Febbraio 2001). Il nuovo pad layout, oltre ad essere più conveniente per il FlexHybrid 4.x, è anche più facilmente compatibile con un wire-bonding previsto per l'MCC-AMS (FlexHybrid 1, 2 e 3, package PLCC-84 e quindi MCCex, schede di test, setup per irraggiamento). Infine tale nuovo layout permette un MCC meno rettangolare e con migliore disposizione dei pin VDD/GND.

Figura 1: MCC-DSM pad layout
La suddivisione delle attività per i prossimi giorni:
La prossima riunione si terrà Giovedi 21 Giugno alle ore 10