52 / 102
DIGITAL
EFFICIENZA ENERGETICA
52
- ELETTRONICA OGGI 463 - GIUGNO/LUGLIO 2017
parte del consumo di energia. Questo fenomeno può
verificarsi in tutte e tre le modalità operative.
Opzioni disponibili per gli utenti di MCU e SoC
Le differenti funzioni delle modalità operative sono ge-
stite da un “power manager”. Ciò è vero sia per le im-
postazioni inziali sia per le transizioni tra le differenti
modalità energetiche. Le modalità operative sono sta-
bilite sulla base del progetto e della suddivisione in-
terna del sistema e del comportamento risultante della
MCU o del SoC.
Le modalità operative risultanti previste dall’attuale
generazione di blocchi a basso consumo sono chia-
mate attraverso istruzioni e bit e dati relativi alle mo-
dalità energetiche, così come da bit e dati di controllo
impostati dall’utilizzatore. Oltre a ciò, è possibile di-
sporre degli elementi contenuti in una libreria softwa-
re, come ad esempio interfacce API. L’insieme di tali
caratteristiche permette di realizzare sistemi e prodotti
efficienti in termini energetici e ottimizzati in base alla
particolare applicazione ma verosimilmente in un am-
bito abbastanza limitato.
Tra sogno e realtà
Per molte applicazioni e linee di prodotti di una società
sono utilizzati numerosi dispositivi di vari fornitori di
MCU/SoC per garantire le migliori prestazioni e la più
lunga vita operativa, unitamente a una serie di fonti di
energia. Funzionalità e modalità energetiche di questi
dispositivi sono attivate direttamente da istruzioni e
bit/dati di controllo. A questo punto è bene doman-
darsi se è possibile ottenere l’accesso diretto al con-
trollo delle funzionalità e delle modalità energetiche
per mezzo di caratteristiche integrate nel codice del
software. L’accesso alle differenti modalità potrebbe
inoltre avvenire in modo sicuro, quindi consentito
solamente tramite una modalità di supervisione attra-
verso un programma centralizzato come ad esempio
un sistema operativo o una funzione di gestione della
potenza (power manager). Un accesso limitato garan-
tisce un funzionamento sicuro duranti i passaggi di
modalità che portano il sistema in condizioni operative
critiche. Le condizioni energe-
tiche definite tramite software
sono di natura flessibile ma
dal punto di vista energetico
le soluzioni software che pre-
vedono frequenti cambiamenti
delle modalità operative non
sono ottimali (Fig. 3). Ciascuna
esecuzione del codice utilizza
la maggior parte dell’hardware della MCU/SoC, che
quindi richiede energia per l’attivazione.
L’obbiettivo principale, ovvero la protezione contro gli
accessi indesiderati nelle MCU/SoC, non è stato ancora
completamente conseguito. Il software è ancora neces-
sario. Le applicazioni che prevedono interrupt o situa-
zioni di tipo “event-driven” che non coinvolgono l’esecu-
zione del codice non sono coperte. Ciascuna esecuzione
del software richiede energia, in quanto vengono attiva-
ti i blocchi hardware base come ad esempio la memoria
principale, il bus di sistema, l’esecuzione del codice in
un kernel e così via. Nella realtà un utente vuole decide-
re la propria modalità operativa. Il produttore dell’har-
dware definisce modalità base e l’utilizzatore sviluppa
e utilizza le proprie modalità operative (come, quando,
dove e così via). Queste modalità operative sono memo-
rizzate in posizioni prestabilite, possono essere o meno
editate ed esiste anche la possibilità di aggiungere mo-
dalità operative definite dall’utilizzatore. Le modalità
operative possono essere dedicate, protette e assegnate
a porzioni hardware e software definite. Oltre a ciò, le
stesse modalità possono essere usate durante gli inter-
rupt senza alcun supporto software (con conseguente
riduzione della richiesta di energia).
Generalmente, le modalità operative descrivono
quelle modalità statiche prestabilite come Run, Idle e
così via. Il metodo qui proposto gestisce in aggiunta
il processo dei cambiamenti di modalità, rispettando
i vari comportamenti dinamici e includendo una tran-
sizione sicura dalla modalità originaria a quella fina-
le. Una transizione sicura richiede l’inclusione di una
risposta sicura (ad esempio con una funzione per la
gestione/correzione degli errori) nel caso tale tran-
sizione non possa essere eseguita o venga eseguita
solo parzialmente, situazione in cui uno stato sicuro è
essenziale (Fig. 4).
Una modalità operativa che includa la gestione del-
la potenza dipende dai dati e non è legata a un com-
portamento definito dal costruttore oppure ai bit e
ai dati di controllo stabiliti dallo stesso. I parametri,
che sono funzione dell’applicazione, possono essere
memorizzati come dati. Nel caso varino le condizioni
Fig. 3 – Andamento dei profili dell’energia: a causa di frequenti cambiamenti tra le diverse modalità
energetiche le correnti di commutazione diventano la principale fonte di perdite (area rossa). Viene
quindi consumata energia senza alcun vantaggio per l’applicazione. Inoltre, se il software viene usato
per le modalità di commutazione (scenario 1c), aumenta lo spreco di energia