4 Flusso d’analisi: sintesi e stima in potenza.
4.1 Struttura dell’ambiente di lavoro.
Per le fasi di simulazione, sintesi e stima in potenza risulta di estrema utilità l’uso di file script. I file script utilizzati che vedremo di seguito, si riferiscono ad un progetto di cui si parlerà più dettagliatamente nel capitolo successivo (si tratta di un microcontrollore 8051). Essi esigono una certa struttura delle directory. In questo lavoro di tesi, si è utilizzata la seguente struttura:
Figura 4-1 Struttura delle directory.
• “sim_vss”: è la directory utilizzata per la simulazione pre-sintesi e post-sintesi. In particolare gli script di simulazione presenti all’interno di “scr” vengono lanciati all’interno di “rundir” (che contiene il file “synopsys_vss.setup”). La directory “log” viene utilizzata per contenere messaggi di errore risultati dalla compilazione. La directory “lib” serve per contenere i file “.sim” e “.mra” prodotti dal comando “vhdlan”.
• “src”: contiene i file “.vhd”. La directory “tb” contiene il testbench. • “syn_dc”: è la directory utilizzata per la sintesi. All’interno di
“CORELIB8DLL” è presente il file “synopsys_dc.setup” insieme con altre directory: “db” contiene i file in formato “.db”, “lib” contiene i file “.mr”, “.st”, “.syn” prodotti dai comandi “analyze” e “elaborate”, “power” contiene dei file utili per l’analisi in potenza, “reports” contiene delle informazioni sul progetto dopo che è stato sintetizzato (area, timing, potenza dissipata ecc.), “results” contiene il file “.vhd” del progetto sintetizzato (utile per la simulazione post-sintesi), “scripts” contiene i file di script per la sintesi e l’analisi in potenza, “wscr” contiene dei file script di comandi dc_shell per salvare gli attributi del progetto corrente.
4.2 Sintesi.
Si è deciso di sintetizzare il microcontrollore 8051 usando la libreria tecnologica CORELIB8DLL_HCMOS8D della STMicroelectronics. In particolare essa è una libreria di standard-cells per progetti digitali VLSI a 0.18 µm. Questa libreria contiene 574 celle combinatorie e sequenziali progettate per lavorare a 1.3V (+10%/-20%) e a 1.8V (+10%/-20%), con un range di temperatura da - 40 °C fino a 125 °C. In particolare si è considerato il best-case in cui la tensione di alimentazione vale 1.95 V e la temperatura vale – 40 °C. Va detto che per i nostri scopi, la scelta di una particolare tecnologia non assume un ruolo determinante, perché come vedremo saremo interessati ad apportare delle
modifiche al codice VHDL del microcontrollare, a sintetizzarlo usando la stessa tecnologia di partenza e a vedere il risparmio percentuale di potenza ottenuto.
All’interno del Design Compiler, il flusso di base per la sintesi è il seguente:
Figura 4-2 Flusso di sintesi.
• Develop HDL files: vengono sviluppati i file VHDL in ingresso al Design Compiler.
• Specify Libraries: vengono specificate le librerie per il Design Compiler. Le link e target library sono librerie tecnologiche che definiscono il set di celle utilizzate e le relative informazioni su di esse. La symbol library definisce i simboli per la vista schematica del progetto (è utile se si lavora col Design Analyzer). La synthetic_library
è una libreria di tipo DesignWare e comprende dei componenti riutilizzabili che sono strettamente integrati all’interno dell’ambiente di sintesi di Synopsys (questi componenti implementano la maggior parte degli operatori VHDL, ad esempio: +, -, *, <, >, <=, >= e le operazioni definite negli statement “if” e “case”).
• Read Design: il Design Compiler usa l’HDL Compiler per leggere progetti RTL (tramite i comandi “analyze” e “elaborate”), oppure netlist gate-level (tramite i comandi “read_file” o “read”).
• Define Design Environment: viene definito l’ambiente del progetto che deve essere sintetizzato (temperatura, alimentazione, tipo di processo, carichi, forze di pilotaggio ecc.).
• Set Design Constraints: per controllare il flusso di sintesi, il Design Compiler usa dei vincoli di progetto (massimi tempi di transizione, massimo fanout, massima capacità ecc.) e dei vincoli di ottimizzazione (sul timing e sull’area massima). I vincoli di progetto hanno una priorità maggiore rispetto ai vincoli di ottimizzazione. Perciò, dapprima il Design Compiler fa una sintesi che rispetti i vincoli di progetto, poi quando passa alla fase di ottimizzazione esegue le opportune modifiche (basate sui vincoli di ottimizzazione) purchè esse non vadano di nuovo a violare i vincoli di progetto.
• Select Compile Strategy: le due strategie di sintesi che si possono usare per ottimizzare qualsiasi progetto gerarchico sono chiamate top-down e bottom-up. Nell’approccio top-down, il progetto top-level e tutti i suoi sottoprogetti sono sintetizzati insieme: tutti i settaggi dei vincoli e dell’ambiente sono definiti in riferimento al progetto top-level. Quindi esso tiene conto automaticamente delle dipendenze tra i blocchi ma non va bene per progetti complessi perché tutti i sottoprogetti devono risiedere in memoria contemporaneamente. Nella sintesi bottom -up, i singoli sottoprogetti sono vincolati e sintetizzati separatamente; dopodichè viene ad essi assegnato l’attributo “dont_touch” per evitare ulteriori cambiamenti durante le successive fasi di sintesi; poi questi sottoprogetti vengono assemblati per dare origine alla sintesi del
successivo livello di gerarchia; questo processo viene iterato salendo in gerarchia fino ad arrivare al top-level. La strategia bottom-up ci permette di sintetizzare dei progetti anche molto complessi perchè non è necessario che tutti i sottoprogetti vengano caricati in mem oria contemporaneamente. Comunque, a ciascuno stadio bisogna stimare i vincoli fra i vari blocchi, e tipicamente bisogna iterare la sintesi, migliorando queste stime, fino a quando l’interfaccia fra i sottoprogetti diventa stabile. Ciascuna strategia ha i suoi vantaggi e svantaggi, ma si può anche usare una strategia di sintesi mista (usando la più appropriata strategia per ciascun sottoprogetto).
• Optimize the Design: tramite il comando “compile” inizia la fase di sintesi e ottimizzazione del progetto.
• Analyze and Resolve Design Problems: il Design Compiler può generare numerosi report (area, constraint, timing, ecc.) sul risultato della fase di sintesi. Oppure si può usare il comando “check_design” per verificare la consistenza del progetto sintetizzato.
• Save the Design Database: il progetto sintetizzato si può salvare tramite il comando “write”.
Per la sintesi del microcontrollore, si è deciso di sintetizzare i singoli sottoprogetti (mc8051_control, mc8051_siu, mc8051_tmrctr, mc8051_alu_DWIDTH8) che compongono il progetto mc8051_core, con una strategia di tipo bottom-up. In questo modo, come si è già visto, i singoli blocchi vengono sintetizzati separatamente e quindi se si vorrà apportare qualche modifica ad un singolo blocco VHDL, per analizzare la percentuale di risparmio in potenza dovuta alla modifica fatta sarà opportuno risintetizzare solo il blocco in questione, mentre gli altri blocchi dovranno mantenere inalterata la loro struttura. Le memorie ROM, RAM e Internal RAM non sono state sintetizzate perché il package TEXTIO (in cui sono definiti i tipi di dato “text” e “lines” per le operazioni di ingresso e uscita durante la simulazione) non è supportato dal VHDL Compiler.
Ma vediamo più in dettaglio il flusso di sintesi utilizzato in questa tesi. In una prima fase sono stati sintetizzati separatamente tutti e 4 i sottoprogetti con i seguenti vincoli:
• create_clock -name "clk" -period 100 -waveform { "0" "50" } { "clk" }: definisce il periodo e il duty cycle del clock.
• set_fix_hold clk: vengono inseriti dei ritardi nei percorsi combinatori che terminano nell’ingresso D dei registri in cui viene violato il tempo di hold.
• set_max_area 0.0: specifica una sintesi a minima area.
• set_min_fault_coverage 95: durante la sintesi il fault-coverage minimo deve essere di 95% ed esso assume una maggiore priorità rispetto ai vincoli di timing e area. Il fault-coverage è una misura della testabilità del progetto e si può definire come la percentuale di difetti che sono rilevati (tramite l’inserzione si scan-cells al post o delle celle sequenziali), rispetto al numero totale di difetti. Tipici esempi di difetti sono: collegamenti flottanti che presentano una tensione casuale (alta o bassa) a seconda della tecnologia, segnali che dovrebbero variare e invece sono cortocircuitati al livello 0 o al livello 1 ecc.
• set_load 0.5 all_outputs(): setta un carico capacitivo di 0.5 pF su tutte le porte di uscita. In base a questa informazione, il Design Compiler sceglie opportunamente la forza di pilotaggio delle celle che pilotano i PAD di uscita.
• remove_design CORELIB8DLL.sdb: CORELIB8DLL: rimuove una libreria dalla dc_shell memory in modo che il comando successivo non vada a usare questa libreria.
• set_driving_cell -lib_cell BFLL all_inputs(): specifica che tutte le porte di ingresso vengono pilotate dalla cella di libreria chiamata BFLL (si tratta di un buffer non invertente).
• read CORELIB8DLL.sdb: carica di nuovo in memoria la libreria precedente.
Dopodichè si caricano nella dc_shell memory tutti questi quattro sottoprogetti (che precedentemente erano stati salvati nel formato .db), si legge il progetto top-level (mc8051_core), si propagano le eccezioni false-path dal livello basso della gerarchia al progetto corrente (i false-path sono dei percorsi combinatori che non sono mai critic i e perciò non devono essere considerati durante la fase di ottimizzazione), si settano anche per il top-level i vincoli elencati di sopra e, inoltre, si setta un ritardo ad esempio di 1 ns (calcolato a partire da un fronte in salita del clock) a tutti gli ingressi ad eccezione del clock. A questo punto, per ciascuna cella (i_mc8051_control, i_mc8051_siu_0, i_mc8051_tmrctr_0, i_mc8051_alu) si può lanciare il comando “characterize” (serve per catturare le informazioni di timing e ambiente di ciascuna cella) e con il comando “write_script” si salvano dei file script (.wscr) che contengono i nuovi vincoli per ciascun sottoprogetto. Utilizzando questi quattro script, si sintetizzano di nuovo e separatamente i quattro sottoprogetti: viene fatta una sintesi di tipo incrementale e inoltre si cerca di risolvere solo le violazioni dei vincoli di progetto senza procedere con un’ulteriore ottimizzazione. Infine si leggono in memoria i sottoprogetti, si assegna loro l’attributo “dont_touch” in modo che non siano rimpiazzati o modificati durante l’ottimizzazione, e si fa la sintesi del top-level (mc8051_core).
4.3 Stima in potenza.
In questo lavoro di tesi, per ottimizzare in potenza il microcontrollore sono state introdotte opportune modifiche al suo codice VHDL e non si è utilizzato il flusso di ottimizzazione proposto dal Power Compiler. In particolare si è utilizzato il Power Compiler solo per l’analisi in potenza (per quantificare il risparmio di potenza ottenuto). I motivi di questa scelta sono i seguenti:
• Più è alto il livello di astrazione a cui si agisce, maggiore sarà la possibilità di risparmio in potenza.
• In questo modo si ha una maggiore libertà e si possono sperimentare diverse soluzioni oltre a quelle proposte da Power Compiler.
• Modificando il codice VHDL, il nuovo microcontrollore può essere sintetizzato e ottimizzato utilizzando uno dei numerosi CAD di sintesi logica (non solo con Synopsys).
• Modificando il codice VHDL, il nuovo microcontrollore può essere sintetizzato e ottimizzato usando tecnologie diverse.
Per quanto riguarda l’analisi in potenza, si è scelta quella più precisa possibile: cioè quella a livello gate e che deriva la switching activity dalla simulazione gate-level. E nello stesso tempo si è fatto variare il tempo di simulazione all’interno di un certo intervallo: ciò consente di avere indicazioni su come varia la potenza media durante l’esecuzione del programma caricato in ROM.
Ma vediamo più in dettaglio il flusso utilizzato per l’analisi in potenza. Si è usato un metodo di cattura della switc hing activity chiamato PowerStats Interface. Il flusso seguito è riportato in Figura 4-3:
vhdlsim
sim2dp
IP_toggle.out IP_gl.vss
TOP.scr
Il comando utilizzato per la simulazione gate-level è il seguente:
vhdlsim -dut / tb_mc8051_top / i_mc8051_top / i_mc8051_core -i ./ power/ vss / IP_gl.vss -togfile ./ power / toggle / IP_toggle.out -power_stats -t ns IP_lib.tb_mc8051_top_sim_cfg_post_syn
In questo modo, il tempo di simulazione è scritto all’interno del file IP_gl.vss e le informazioni di switching activity vengono scritte (in formato toggle) nel file IP_toggle.out. Un file toggle è un file ASCII che contiene una lista del tipo:
Figura 4 -4 File d’uscita di VSS – togfile.
In questo file di uscita, ciascuna riga corrisponde ad un pin d’uscita di ciascun componente gate -level del progetto. Nella prima colonna è indicato il nome dell’elemento, ne lla seconda e terza è riportato il totale delle commutazioni e degli “hazard” avvenuti durante il tempo di simulazione, infine nelle ultime tre colonne è riportato il tempo totale in ciascun stato logico. E’ da notare che questo file non contiene informazioni circa le SDPD (State-Dependencies e Path-Dependencies) che possono esistere tra le varie celle di libreria. Dopodichè, per convertire questo file di tipo toggle, in un file script di comandi set_switching_activity viene utilizzata l’utility sim2dp. Il comando da eseguire è il seguente:
/ VLSI / soft / synopsys - 2001.08 / syn / auxx / syn / power / scripts / sim2dp -strip_name " / TB_MC8051_TOP / I_MC8051_TOP / I_MC8051_CORE / " -vss ./ power / toggle / IP_toggle.out > ./ scripts / TOP.scr
L’opzione “– strip_name” serve per togliere da ogni nome degli elementi nel file di uscita la stringa: " / TB_MC8051_TOP / I_MC8051_TOP / I_MC8051_CORE / ". Infatti è a partire da questo livello di gerarchia che si è iniziato a sintetizzare. Lanciato questo comando, viene prodotto il file “TOP.scr” che contiene dei comandi del tipo:
set_switching_activity period 10000000.00 toggle_rate 199999 -static_prob 0.500000 find(port,"CLK") ;
Dove “period” è il tempo di simulazione, “toggle_rate” è la somma delle transizioni in salita (0→1) e in discesa (1→0) che il segnale compie durante il tempo di simulazione, “static_prob” è la frazione di tempo in cui il segnale sta a livello logico alto, cioè: sp =T(1)/(T(1)+T(0)).
Dopodichè si cambia la target_library: ora si usa una libreria tecnologica caratterizzata in potenza: SYNOPSYS_DP (che non si era utilizzata precedentemente perché essa contiene informazioni in più rispetto alla libreria tradizionale SYNOPSYS_DC e quindi ciò avrebbe potuto rallentare la sintesi), si legge il progetto mc8051_core precedentemente sintetizzato e col comando “translate” si convertono tutti i componenti del progetto nei componenti della nuova target_library (il comando “translate” non opera su celle o progetti che hanno l’attributo “dont_touch”, quindi prima di lanciarlo bisogna rimuovere questi attributi, se ne esistono). Durante la fase di translate si è incontrato qualche problema: infatti questa operazione terminava non normalmente e venivano segnalati dei messaggi di errore. Questi messaggi erano: OPT-128 (ci sono conflitti tra celle in due librerie con lo stesso nome ma con percorso diverso caricate contemporaneamente nel Design Compiler) e OPT-106 (ci sono delle celle linkate a celle di libreria che hanno lo stesso nome di alcune celle all’interno della nuova target_library). Per risolvere questi problemi, si è deciso di sostituire nel search_path e nella link_library rispettivamente il percorso ed i file riguardanti la vecchia libreria SYNOPSYS_DC con quelli riguardanti la nuova libreria SYNOPSYS_DP. Poi si è fatto un apposito link manuale (col comando
“link”) per risolvere i riferimenti del progetto. Si ricorda che il search_path indica le directory a cui appartengono i file di libreria o di progetto che sono specificati senza nome directory. In questo modo si è potuta eseguire una corretta fase di translate.
A questo punto vengono eseguiti i comandi di “set_switching_activity” (tramite lo script “TOP.scr”) e infine si lancia il comando “report_power” che calcola e riporta la potenza per il progetto.
