Tradizionalmente le principali problematiche e gli obiettivi in termini di ottimizzazione durante lo sviluppo di un chip si possono riassumere in questo acronimo di tre lettere: PPA (Performance, Power, Area, ovvero prestazioni, consumo di potenza e area occupata). A secondo del dominio applicativo, l’importanza relativa di questi tre obiettivi di progetto può variare in modo considerevole. Nel caso dei dispositivi mobili, il consumo di potenza è stato per lungo tempo uno dei parametri critici. Nei braccialetti per il fitness, dispositivi medicali e altri prodotti che si trovano alla periferia di una rete IoT, la potenza può essere così scarsa e importante, che la raccolta di energia (energy harvesting) durante il funzionamento diventa critica. Per contro, nel caso di dispositivi alimentati mediante una presa da parete come i server e numerosi altri prodotti consumer, il consumo di potenza potrebbe avere un impatto minore, ma in questo contesto gli effetti termici assumono un’importanza critica. Inoltre, sarebbe importante domandarsi se un determinato package possa gestire in modo adeguato il consumo di energia oppure sia necessario disattivare alcune sezioni di un dispositivo per prevenire il surriscaldamento. Ciò interessa anche le applicazioni mobili dove in alcuni casi, per esempio con AnTuTu (utilizzato per la misura delle prestazioni dei telefoni mobili), i punteggi dei benchmark hanno iniziato a diminuire in un secondo momento durante il funzionamento poiché erano stati raggiunti i limiti termici per cui era necessario disattivare una parte della potenza di elaborazione.
Come visibile in figura 1, esaminando i vari componenti di un chip, dai circuiti analogici e a segnali misti all’hardware di controllo, l’hardware per il dataflow, la memoria e il software, gli ultimi tre hanno il maggior impatto sui consumi di potenza, in special modo ai più elevati livelli di astrazione. I progettisti prendono parecchie decisioni che influenzano in maniera significativa il consumo di potenza del design. Gli architetti impegnati nello sviluppo della micro-architettura che adottano un algoritmo definito in C o System C e decidono come implementarlo si trovano ad affrontare numerose aree che hanno un impatto non indifferente sull’ottimizzazione del progetto a basso consumo di potenza (low power): selezione dell’ampiezza dei bit (bit width); individuazione dei compromessi più idonei tra prestazioni, tensione e consumo di energia; ottimizzazione delle attività di progetto; definizione del miglior rapporto tra area e consumo di energia; ottimizzazione della memoria; tecniche di clock gating (ovvero di disattivazione della logica non coinvolta nell’elaborazione), gestione dinamica della tensione (voltage scaling) oltre a vari compromessi a livello hardware/software. Se, per esempio, specifiche funzioni possono essere trasferite dal software all’hardware a livello architetturale, è possibile ottenere significative riduzioni della potenza. In questo caso sono richiesti modelli a livello di sistema, peraltro non difficili da ottenere: grazie a essi è possibile eseguire una simulazione ad alta velocità su una quantità di dati ragionevole ma con un’accuratezza limitata. Nel momento in cui si procede verso la fase di implementazione a livello RTL (Register-Transfer Level), il numero di opzioni disponibili per ridurre il consumo di energia è ancora abbastanza elevato, consentendo quindi un margine di manovra ragionevole. Sezioni specifiche del progetto possono essere commutate dinamicamente in modalità a basso consumo di potenza (low power), cercando di individuare un compromesso tra prestazioni e consumi di energia durante l’esecuzione.
Tra i metodi più diffusi si possono annoverare la riduzione della frequenza di campionamento o il ricorso alla tecnica di clock gating completa applicata a determinate sezioni del progetto. Operazioni quali l’ottimizzazione della condivisione delle risorse, l’isolamento degli operandi e l’ottimizzazione della codifica degli stati del controllore e del bus possono contribuire a ridurre le capacità che devono essere commutate. In linea di principio, a questo stadio, è ancora possibile apportare modifiche a livello architetturale. Un utente, per esempio, potrebbe variare il numero dei moltiplicatori per ridurre l’attività di commutazione attraverso l’utilizzo della correlazione tra dati successivi in un flusso di dati. In ogni caso gli utenti in questa fase focalizzano completamente la loro attenzione sulla verifica funzionale. I tempi di simulazione iniziano ad assumere una certa importanza e le risorse impiegate per il progetto della descrizione RTL spesso impedisce di concentrare l’attenzione sull’ottimizzazione del consumo di energia a questo livello di astrazione. Dopo la sintesi logica per la netlist a livello di gate, il consumo di energia dinamico può essere determinato in maniera abbastanza accurata in funzione delle attività del progetto. A questo livello, i team di progetto possono ricorrere a ottimizzazioni minimizzando le capacità che devono essere pilotate dai nodi più attivi del progetto. Il consumo di energia, inoltre, può essere ottimizzato tramite un bilanciamento dei ritardi del percorso, in modo da impedire fenomeni di “spike”, transizioni spurie e ri-temporizzazioni.
A questo livello di astrazione l’accuratezza della stima dei consumi di potenza è abbastanza elevata, anche se la quantità di dati da gestire aumenta in modo significativo. Anche se la simulazione a livello di gate viene effettuata senza back annotation a livello di timing, gli utenti devono tenere in considerazione tempi lunghi per la simulazione. Una volta che i team di progetto sono pervenuti alla fase di layout, con conseguente generazione del file GDSII per la effettiva implementazione (produzione maschere fotolitografiche), è disponibile una quantità di dati sufficiente per consentire una simulazione e una stima accurate del consumo di energia. A secondo delle stime effettuate a questo livello di astrazione, i team di progetto possono effettuare un dimensionamento dei transistor e una riorganizzazione del layout in base al piazzamento e alle interconnessioni. L’accuratezza a questo livello di astrazione è molto alta ma la quantità di dati che deve essere elaborata e la velocità di simulazione sono così limitate che è possibile utilizzare solamente un numero ridotto di vettori di test per l’analisi. In questo caso la possibilità di influire sui consumi di energia è relativamente bassa poiché non è più possibile apportare modifiche di rilievo al progetto, come per esempio modifiche del numero di risorse aritmetiche.
In conclusione, per l’ottimizzazione dei consumi ci si trova di fronte a un dilemma: mentre le decisioni ai più elevati livelli di astrazione a livello di sistema hanno il maggior impatto, essere sono prese sulla base dei dati meno accurati disponibili per il progetto in quel momento. Per contro, nel momento in cui sono disponibili i dati più accurati, ovvero a livello di layout, l’impatto delle modifiche basate su questi dati è relativamente modesto, mentre i tempi di simulazione sono molto lunghi. Per affrontare in modo efficace questo problema, gli utenti devono poter disporre di tecniche che consentano di abbinare cicli di simulazione «profondi», compresa l’esecuzione del software, con informazioni accurate ottenute dalla definizione della libreria della tecnologia dei semiconduttori.
Collegare i livelli di astrazione
Come illustrato in figura 2, se in un progetto non viene effettuato un numero sufficiente di cicli, incluso il software eseguito sui suoi processori, gli utenti rischiano di essere bloccati su un valore minimo locale. Per determinare il consumo di potenza nel caso peggiore (worst case) sono necessari cicli “profondi”.
L’impiego dell’emulazione abbinata alla stima dei consumi ottenuta dalla descrizione RTL o a livello di gate permette di collegare i livelli di astrazione. Grazie alla disponibilità di soluzioni di emulazione come Palladium Z1 Enterprise Emulation Platform di Cadence, gli utenti possono acquisire un gran numero di dati relativi all’attività in un lasso di tempo relativamente breve e collegarli ai flussi di implementazione. Anche se l’emulazione consente l’esecuzione nel range dei MHz rispetto alla simulazione che viene eseguita nel range degli Hz, l’identificazione degli “hot spot” corretti può essere dedotta partendo da un’informazione dell’attività più astratta, più grossolana (course grain), come il conteggio dei toggle (TC – Toggle Count, ovvero numero dei cambiamenti sui segnali) per il progetto, dove ogni toggle viene considerato come una unità, finalizzato a ottenere una stima iniziale. Dopo aver definito con maggior precisione l’area di interesse, è possibile ricorrere ai conteggi dei toggle ponderati. In pratica si attribuiscono pesi su differenti reti a seconda della loro importanza, per esempio considerando un toggle di write-enable (abilitazione alla scrittura) più significativo rispetto a un toggle relativo all’ingresso di una porta NAND. In questo modo è possibile ottenere una maggiore accuratezza. Il più elevato livello di accuratezza può essere ottenuto utilizzando il formato SAIF (Switching Activity Interchage Format) per il conteggio dei toggle che assicura un’accuratezza a grana fine. Questo formato può quindi essere utilizzato da tool per il calcolo dei consumi di potenza come Joules RTL Power Solution di Cadence che tiene in considerazione i dati della tecnologia di basso livello ottenuti dalle definizioni; lib.
La figura 3 mostra il flusso di progetto risultante oltre a un esempio dell’ambiente di debug del profilo dei consumi di potenza che include il conteggio dei toggle e la visualizzazione di un’interruzione dell’alimentazione (PSO – Power Shut Off).
I team di progettazione possono anticipare le fasi relative all’ottimizzazione dei consumi di potenza nel corso del ciclo di progetto utilizzando: (1) una combinazione dei dati dell’attività desunti dal livello RT con stime del consumo di potenza ottenuti dalla descrizione RTL utilizzando informazioni relative alla tecnologia contenute nei file; lib oppure (2) sfruttando informazioni relative all’attività desunte dal livello di gate corredate da dati aggiornati relativi sulla potenza che possono essere aggiunte direttamente ai file; lib. Ciò permette di evitare costosi re-design che sarebbero necessari nel caso si scoprissero problemi relativi alla potenza da correggere in stadi più avanzati del progetto. Esso consente anche ai progettisti di ottimizzare la potenza utilizzando il software che gira sui processori che fanno parte del progetto e può avere un impatto notevole sul consumo di potenza dinamico.
Utilizzo di formati standard come IEEE 1801
IEEE 1801/UPF è uno standard definito da IEEE che specifica il “power intent” (la specifica dei requisiti di potenza) sfruttando un file separato attraverso comandi tipo TCL oppure un “power intent” scritto direttamente nella descrizione hardware attraverso attributi del linguaggio e linguaggi HDL. Lo standard definisce i differenti domini di potenza e vari tool, come l’emulazione e la simulazione, che possono impiegare il codice conforme a IEEE 1801 per aiutare gli utenti a rappresentare il “power intent”. Quando si considera un progetto con quattro domini di potenza – tre dei quali sono commutabili mentre il quarto, anch’esso commutabile, prevede stati ad alta e bassa tensione – gli utenti devono collaudare nove stati base e 24 modalità di funzionamento. Questo test può essere effettuato sfruttando la simulazione e l’emulazione. Sebbene alcune di tali modalità potrebbero non essere significative, quando vengono abbinate con centinaia o addirittura migliaia di test funzionali, si incomincia a intravedere l’impatto imputabile alla sovrapposizione del progetto a bassa potenza al problema della verifica. A questo punto appare chiara l’importanza della potenza di calcolo offerta dell’emulazione, grazie alla quale è possibile le potenzialità della simulazione. Un tipico test funzionale potrebbe essere ampliato al fine di includere i segnali per il controllo della potenza. Per la verifica del PSO (Power Shut Off), per esempio, i cicli per attivare l’isolamento danno inizio alla sequenza, seguiti dal mantenimento dello stato e successivamente dall’attivazione dell’arresto graduale della potenza (power shutdown) del dominio per la verifica dell’operazione.
La figura 4 riporta alcuni controlli che dovrebbero essere eseguiti. Nel momento in cui si procede alla valutazione del supporto offerto dall’emulazione per IEEE 1801, gli utilizzatori dovrebbero verificare funzionalità specifiche che hanno implicazioni ben definite sulle stesse, per esempio la randomizzazione della memoria durante le fasi di spegimento e di accensione, il controllo del valore di lettura durante lo stato di power off, la conservazione (retention) dello stato della memoria non volatile e il «freezing» (congelamento) dei dati durante la retention sono elementi importanti da tenere in considerazione per assicurare la ripetibilità della verifica di un progetto low power. Gli utilizzatori dovrebbero essere consapevoli del fatto che in fase di emulazione – effettuata utilizzando per esempio la piattaforma Palladium Z1 – si deve tener conto di un sovraccarico (overhead) in termini di capacità in misura compresa tra il 10 e il 20% associato alla verifica di un progetto low power conforme a IEEE 1801 imputabile all’inserimento automatico di logica per il controllo della gestione del dominio della potenza. Il flusso di lavoro in emulazione della piattaforma Palladium Z1 richiede una modifica del codice utente esistente per integrare il file di «power intent» IEEE 1801 durante la fase di compilazione, mentre il resto del flusso è completamente automatizzato.
Alcuni esempi pratici
Per l’analisi della potenza dinamica, un esempio è stato proposto durante l’ultima edizione di CDNLive che si è tenuta nella Silicon Valley nel corso di una presentazione di Theodore Wilson, technical lead for Architecture Co-Verification di Microsemi, dal titolo, «Rapid Turns with Palladium and Joules». Il parametro chiave che Microsemi stava cercando di ottimizzare era: «l’analisi di potenza intesa come flusso – il tempo che intercorre tra il tracciamento dell’attività ai report della potenza utilizzabile». L’abbinamento tra la piattaforma Palladium Z1 e le stime della potenza ottenute mediante il tool Joules, Microsemi è stata in grado di effettuare esecuzioni a livello di gate non appena disponibile una descrizione RTL funzionante: il tutto è stato eseguito nelle fasi iniziali e in modo accurato e preciso. Altri utenti, come per esempio Texas Instruments, hanno riportato che la corrispondenza tra i risultati relativi ai consumi di potenza previsti ottenuti dall’emulazione e quelli rilevati nel flusso di implementazione è stata pari al 96%. L’esecuzione di emulazione per un periodo di tempo più lungo rispetto a quello impiegato per la simulazione ha permesso di scoprire condizioni di consumi di potenza non previsti poiché il progetto era stato fatto girare in emulazione con software utilizzato in casi d’uso reali.
Samsung ha sperimentato l’impatto dell’ottimizzazione della potenza basato sullo standard UPF 1801 e ne ha discusso durante la recente edizione di CDNLive che si è tenuto in Corea («The Power of Big Iron,»). Con un minimo onere aggiuntivo in termini di capacità e tempi di compilazione, Samsung è stata in grado di migliorare i tempi di esecuzione dei test condotti di un fattore compreso tra 5 e 32. La possibilità di far girare i test in un tempo decisamente inferiore, o di effettuare più test nello stesso lasso di tempo, rappresenta sempre un vantaggio per gli utenti che effettuano l’emulazione. Il collaudo “power-aware” (ovvero che tiene conto dei consumi di potenza) permette ora di effettuare la verifica del firmware e del software in contemporanea con il collaudo dell’hardware. Questa espansione permette di ampliare le possibilità di ottimizzare l’architettura di potenza. Gli utenti, inoltre, possono avere un bring-up (valutazione elettrica e funzionale) del silicio più veloce nell’ambito di una strategia di progettazione low power.
