Nel settore spaziale, la crescente complessità dei sistemi di bordo, da un lato, e la specificità dei requisiti funzionali, dall'altro, precludono in molte applicazioni l'utilizzo di componenti off-the-shelf spingendo quindi allo sviluppo di soluzioni custom. Sebbene consenta migliori prestazioni, tuttavia, tale approccio presenta una evidente componente di rischio che deve essere opportunamente considerata. Nel 1999, ad esempio, il satellite Wire della Nasa (costato 79 milioni di dollari) ebbe un malfunzionamento appena immesso in orbita che determinò la perdita di funzionalità della strumentazione a bordo. Successive analisi rilevarono un problema nella logica di controllo del rilascio della copertura del telescopio; l'errore era legato ad un progetto non corretto del circuito di reset interno della Fpga di controllo e ad una non approfondita documentazione del comportamento dei pin di I/O del dispositivo durante la fase di power-up.
Per ridurre i rischi inevitabili legati ad implementazioni custom, l'Agenzia Spaziale Europea ha stilato un documento di riferimento che traccia le linee guida da seguire nel progetto di Fpga/Asic per applicazioni spaziali dal punto di vista della gestione programmatica, dell'ingegnerizzazione del dispositivo e della qualità. L'obiettivo è assicurare che lo sviluppo di componenti custom risulti compatibile con i requisiti generali di funzionalità, qualità, affidabilità, pianificazione e costi.
Di seguito è riportata una breve descrizione delle indicazioni principali fornite dal documento. Le Figg. 1 e 2, in particolare, mostrano uno schema di principio piuttosto generico del flusso di progetto tracciato; in funzione della complessità e criticità dei programmi e dei costi sostenibili, piani di sviluppo semplificati possono essere di volta in volta derivati da questo. Sono previste in generale cinque diverse fasi:
- definizione dei requisiti
- progetto di architettura
- progetto di dettaglio
- layout
- implementazione del prototipo
- validazione del progetto e rilascio del dispositivo.
Ogni fase si conclude, in particolare, con la produzione di documentazione di riferimento o di progetto che concorre a realizzare l'insieme degli oggetti deliberabili del programma oltre che il punto di partenza delle fasi successive. Il punto originario è il piano di controllo (Asic/Fpga Control Plan) che deve includere, almeno, una descrizione della struttura organizzativa dell'azienda, dell'approccio di gestione che si intende seguire, dell'intera pianificazione, definendo nettamente interfacce e responsabilità ed indicando le procedure applicabili per la riduzione dei rischi.
La definizione dei requisiti
La prima fase di un programma di sviluppo di Fpga/Asic prevede la definizione dei requisiti di progetto, lo studio di fattibilità e l'analisi dei rischi; i documenti prodotti al termine dell'attività sono il piano di sviluppo (Asic/Fpga Development Plan) per quanto riguarda la parte di gestione del progetto, il documento di specifica (Asic/Fpga Requirement Specification) per gli aspetti di ingegnerizzazione e l'analisi di fattibilità e rischi per la qualità (Feasibility and Risk Analysis Report).
Scopo del documento Adp, ad esempio, è quello di identificare le principali fasi di sviluppo del programma, indicando per ognuna i ruoli e le responsabilità del personale coinvolto, le risorse da utilizzare in termini di apparecchiature e tool software oltre alla loro disponibilità, gli output da produrre, le milestone da rispettare ed il tipo ed il numero di review di progetto da superare. Devono essere riportati l'identificazione del sistema di gestione della configurazione che si intende seguire, lo schema di verifica e validazione che sarà adottato, la suddivisione dei pacchetti di lavoro con una stima della durata per ognuno; ove richiesto deve essere fornita una indicazione preliminare della tecnologia selezionata e dell'approccio che si intende seguire per assicurare la tolleranza alla radiazione del dispositivo finale. Nel caso di dispositivi per i quali sia necessaria la disponibilità su lungo periodo o la compatibilità con requisiti da utenti e missioni diversi, infine, deve essere evidenziata la strategia di mantenimento e portabilità del progetto.
L'Ars, invece, rappresenta il documento di riferimento della parte progettuale; deve includere almeno una descrizione preliminare dei modi operativi del sistema, indicazioni sulla configurazione e sul partizionamento eventuale delle funzionalità, le specifiche delle interfacce verso periferiche esterne, eventuali constraints di natura elettrica ed ambientale, le procedure per la gestione degli errori. Devono essere evidenziati la riutilizzabilità del dispositivo ove possibile in applicazioni future, la portabilità verso nuove tecnologie, eventuali parti di proprietà intellettuale che si intende utilizzare o da sviluppare.
Rispetto a tali requisiti, infine, deve essere condotta una analisi di fattibilità del progetto e dei rischi associati riportata nell'Fra. L'analisi di rischio, in particolare, deve assicurare che tutti i requisiti forniti siano completi, non ambigui e consistenti e che le tecnologie selezionate siano mature; deve accertare l'esperienza delle risorse ingegneristiche indicate a lavorare nell'ambito in questione e con le problematiche in oggetto. Devono essere evidenziati gli eventuali rischi cui si andrebbe incontro nel caso si fossero sottostimati, dal punto di vista programmatico, gli sforzi necessari alla progettazione o, dal punto di vista tecnico, la disponibilità di adeguate risorse e tecnologie per il soddisfacimento dei requisiti.
Questa prima fase di si conclude con la System Requirement Review il cui scopo è verificare che le attività di sviluppo previste siano in accordo alle specifiche generali di progetto e conformi alle limitazioni imposte in termini di risorse, pianificazione e costi; deve essere approvato che la documentazione prodotta è coerente e completa includendo tutti i dettagli necessari all'inizio della successiva fase di progetto di architettura.
Il progetto di architettura
La seconda fase nello sviluppo di Fpga ed Asic consiste nella progettazione dell'architettura del dispositivo.
Dal punto di vista ingegneristico, in particolare, devono essere confermate le scelte critiche di base tracciate nelle fase precedente per quanto riguarda, ad esempio, la selezione della tecnologia per la realizzazione del dispositivo e le stime in termini di prestazioni e budget; eventuali deviazioni dalle specifiche approvate devono essere opportunamente descritte e giustificate. L'architettura deve essere dettagliata fino al livello necessario alla implementazione verso tecnologie specifiche a livello transistor o gate-level; devono essere individuate le parti di logica che possono essere considerate come unità funzionali autoconsistenti e riutilizzabili al punto di giustificare lo sviluppo interno o l'acquisto da terze parti di core di proprietà intellettuale; particolare attenzione deve essere dedicata alla definizione dello schema di clocking e di reset del dispositivo. Devono essere generati dei modelli funzionali - ad esempio modelli Rtl sintetizzabili - che possano servire come base per la successiva fase di progetto di dettaglio; non è richiesto lo sviluppo invece di modelli di riferimento basati, ad esempio, su descrizioni puramente comportamentali ad un livello più alto di astrazione, anche se è espressamente fatto notare che tale sforzo rappresenta sicuramente un valore aggiunto per i successivi scopi di verifica. Devono essere emessi un report di progetto con la descrizione delle soluzioni architetturali adottate ed un datasheet preliminare del dispositivo.
Il piano di verifica da seguire è dettagliato invece nel Verification Plan; tale documento deve includere, ad esempio, i requisiti di code coverage, le specifiche per una eventuale co-simulazione hw/sw, una valutazione della possibilità di prototyping su Fpga od emulazione su piattaforme generiche nel caso di Asic complessi. Rispetto ai requisiti indicati nel piano deve essere condotta quindi l'analisi di verifica dell'architettura progettata; i risultati devono essere tracciati in un report dedicato. Devono essere documentati, in particolare, il rispetto dei requisiti di progetto dal punto di vista delle funzionalità, prestazioni e caratteristiche; nel caso di requisiti in controtendenza (si pensi ad esempio alla selezione della frequenza di clock utilizzata rispetto alla dissipazione di potenza del dispositivo) le scelte adottate devono essere giustificate come conseguenza di una trade-off analizzato in fase di verifica. Nel caso di Asic e laddove si ritenga che l'allocazione e la connessione di hard-macro possa costituire un punto critico nelle successive fasi, deve infine essere condotto un floor-plan preliminare del dispositivo. Come risultato dell'analisi di verifica, infine, deve essere rivisto il piano di fattibilità e l'analisi di rischio del progetto.
La fase di progetto architetturale si conclude con la Preliminary Design Review dove la documentazione emessa viene discussa ed approvata. In particolare, deve essere verificato che le scelte adottate ed i trade-off tracciati siano in linea con i requisiti approvati nella precedente fase, che i rischi siano stati correttamente rivalutati e che esista un piano contingente adeguato nella loro gestione.
Il progetto di dettaglio
Scopo della fase di progetto di dettaglio è la traduzione della descrizione strutturale del dispositivo realizzata precedentemente in celle elementari della tecnologia selezionata. Le principali attività svolte sono design entry, generazione della netlist e verifica di questa.
La fase di design entry prevede l'implementazione delle funzionalità di test e degli eventuali accorgimenti per soddisfare i requisiti di tolleranza alla radiazione del dispositivo. Devono essere specificati il pin-out e le caratteristiche dei buffer di I/O; nel caso di Asic, inoltre, deve essere determinato lo schema di bonding per il packaging del componente e tracciate le linee guida per il floor-plan. Tali informazioni confluiscono in un report dedicato. La successiva generazione della netlist deve tenere conto dei fattori di derating indicati nelle specifiche; opportune raccomandazioni emesse per le applicazioni in ambito spaziale indicano i valori da assumere per i diversi parametri. La possibilità di imporre constraint peggiorativi rispetto ai requisiti deve essere considerata per compensare l'eventuale degrado delle prestazioni a causa di effetti parassiti; modelli opportuni di tali parametri devono essere derivati. Inoltre, qualora siano utilizzati tool di sintesi automatica, devono essere generati gli script di configurazione in modo da consentire la ripetibilità del processo; essendo parte integrante della documentazione di progetto, tali scritp devono sottostare al controllo di documentazione approvato per il progetto.
La netlist sintetizzata deve quindi essere verificata del punto di vista funzionale utilizzando lo stesso ambiente sviluppato durante il progetto architetturale o mediante metodi diversi quali verifica formale ed analisi timing statica. Qualora il piano di validazione preveda prove di funzionamento di pre e post burn-in devono inoltre essere generati i vettori di test. Nel caso siano stati imposti requisiti di tolleranza a radiazione, tale aspetto deve essere verificato mediante simulazione con iniezione di Seu nella logica del dispositivo ed ispezione della netlist sintetizzata. Oggetto di verifica devono essere anche la frequenza di lavoro richiesta, il massimo consumo di potenza atteso o, nel caso di Asic, la conformità ai requisiti elettrici. Al fine di soddisfare tutti requisiti, la specifica contempla la possibilità di iterazioni successive tra le fasi di design entry, generazione e verifica della netlist. È invece fortemente raccomandato di evitare ritorni alla fase di progetto architetturale a meno che non si evidenzino problemi insuperabili; in questo caso tuttavia l'attività di validazione inerente a quella fase deve ovviamente essere ripetuta. Al termine della fase di validazione deve essere aggiornato il datasheet preliminare del dispositivo ed il database di progetto includendo la netlist pre-layout, eventuali constraint per la fase di layout ed i vettori di test da utilizzare per i test di produzione.
La fase di progetto di dettaglio si conclude con la Detailed Design Review. Come nel caso precedente devono essere approvati i documenti di progetto e verificato il rispetto dei requisiti.
La fase di layout
La successiva fase di layout prevede la finalizzazione del floor-plan e il place&route del dispositivo tenendo in conto i constraints fisici e di timing per la generazione dei dati necessari alla creazione dei file di programmazione e maschera (Idmp). Nel caso di Asic, in particolare, devono essere disegnate le reti di distribuzione interna dell'alimentazione e del segnale di clock, determinata la dimensione del die e prodotti i diagrammi di bonding ed i constraint di packaging. Il layout finale è sottoposto a verifica mediante controlli Drc (Design Rule Check) ed Erc (Electrical Rule Check). Dai file Idmp, infine, deve essere estratta una netlist oggetto di verifica mediante confronti Lvs (Layout versus schematica) o metodi Ncc (Netlist comparison check); devono essere estratti i parametri parassiti del dispositivo, stimati i timing di I/O rilevanti, verificata la latenza e lo sk
ew della rete di clock. Il datasheet del componente deve essere consistentemente aggiornato; la netlist nel formato concordato deve essere inclusa nel database di progetto. Oltre ai report relativi alle attività di generazione e verifica del layout, deve infine essere emesso il Design Validation Plan recante indicazioni sulle misure da eseguire sui prototipi al fine di verificare la corretta implementazioni di funzionalità e specifiche. In accordo a quanto specificato nell'Adp, il Dvp deve includere almeno una descrizione del setup di test e dei modi operativi e delle condizioni di test del prototipo; ove richiesto dal programma, deve essere data evidenza del piano di verifica dei requisiti di tolleranza a radiazione del dispositivo.
La fase di layout si conclude con la Cdr (Critical Design Review) che deve approvare la documentazione di progetto prodotta ed autorizzare la fase di produzione dei prototipi.
Implementazione del prototipo
Tale fase prevede la realizzazione del numero di prototipi previsti dall'Adp; la specifica raccomanda che tutti siano testati secondo il piano di verifica approvato eventualmente includendo procedure di burn-in. Test report completi devono essere compilati ed emessi; i log delle apparecchiature di test utilizzate devono essere distribuiti in formato elettronico. Non è prevista in questa fase una review finale.
Validazione del progetto e consegna del dispositivo finale
L'ultima fase dello sviluppo di Fpga ed Asic serve a dimostrare il raggiungimento dei requisiti funzionali, di prestazioni, di interfaccia e di compatibilità stabiliti in sede di definizione delle specifiche del programma. L'attività di validazione, in particolare, deve consentire di verificare tutte le funzionalità ed i modi operativi del dispositivo in tutte le condizioni corrispondenti a situazioni reali; i parametri misurati devono essere confrontati con quelli specificati. I report di verifica devono essere resi disponibili alla fonderia ed alla design house. Qualora i livelli di tolleranza alla radiazione richiesti non siano già stati dimostrati per la tecnologia adottata, inoltre, i prototipi devono essere sottoposti a test opportuni in accordo alle procedure di test previste nel Dvp.
La fase finale di consegna del dispositivo deve prevedere la stesura di un accordo di concessione di licenza per le parti di proprietà intellettuali incluse nel dispositivo che copra l'intera vita del programma. Il produttore deve inoltre assicurare supporto tecnico durante tale periodo o, in alternativa, trasferire le competenze necessarie in merito direttamente alla fonderia od una terza parte. L'intero database di progetto (includendo la documentazione associata, i programmi di test, il set delle maschere) deve essere mantenuto dal produttore. Nel caso di produzione presso fonderie non espressamente qualificate rispetto ai requisiti Qml, deve essere concordato con il cliente un piano di valutazione delle caratteristiche di questa. La documentazione finale deve includere il report di validazione, le specifiche dettagliate e il datasheet aggiornati, una application note. Nell'ottica, inoltre, di un costante miglioramento delle procedure di qualità interne e per una migliore comprensioni dei requisiti di sviluppo da imporre per futuri progetti, è richiesto che il produttore produca un report sull'esperienza acquisita durante il programma; dovrebbero essere inclusi un sommario dei principali obiettivi e constraint, considerazioni su prestazioni ed affidabilità dei tool Eda utilizzati, valutazioni di eventuali fornitori e fonderie, l'esposizione di aree problematiche o aspetti di non conformità, raccomandazioni e lezioni apprese.
L'attività si conclude con la Qualification and Acceptance Review (QR/AR) con lo scopo di verificare che l'intero programma abbia rispettato i requisiti imposti e che gli eventuali rischi prospettati per la produzione dei componenti da utilizzare per la produzione dei modelli di volo siano accettabili.
