Le architetture di tipo SoC si stanno rapidamente evolvendo verso l’integrazione, all’interno di un singolo pezzo di silicio, di svariati core, sia aventi funzioni di microcontrollore che orientati all’esecuzione di applicazioni. Gli architetti dei sistemi vedono in ciò una incredibile opportunità per estendere molteplici funzionalità distinte, consolidandole su questi processori multicore eterogenei, ma al contempo stanno anche realizzando che il consolidamento di ambienti operativi eterogenei su un singolo SoC costringe ad affrontare alcune sfide del tutto peculiari, sia di tipo architetturale che relative allo sviluppo del codice. Le architetture operative di tipo Smp (Symmetric MultiProcessing) consentono infatti l’utilizzo di tecniche di load balancing per il bilanciamento del carico applicativo tra processori omogenei all’interno di una infrastruttura multicore, ma non possono essere estese agli ambienti con core eterogenei. Inoltre, se da un lato le architetture di sistema di tipo Amp (Asymmetric MultiProcessing) sono sempre più richieste, dall’altro vi è una carenza di standard condivisi e di paradigmi per la progettazione del software che consentano di sfruttare appieno i vantaggi offerti dalle architetture Amp. Solo la disponibilità di alcuni particolari meccanismi può infatti permettere alle applicazioni Amp di far leva in modo efficiente sul parallelismo offerto dai processori eterogenei presenti all’interno di una configurazione multicore.
L’automazione in fabbrica
Quale semplice esempio, consideriamo il caso di un robot per l’automazione di una linea produttiva, in cui il controllo real-time del robot sia affiancato da svariate funzionalità di tipo non real-time, che potrebbero includere i meccanismi di comunicazione per il monitoraggio di tipo Scada, l’interfaccia uomo-macchina, oppure le funzioni per il logging dei dati. All’interno di un ambiente consolidato eterogeneo, il controller del robot sarebbe probabilmente realizzato mediante l’esecuzione di un Rtos, come Nucleus di Mentor, o forse di un microcontrollore. Le rimanenti funzionalità potrebbero invece essere eseguite su un microprocessore. Il sistema consolidato dovrebbe inoltre essere in grado di supportare il boot del sistema, le funzioni di comunicazione, essere ottimizzato rispetto alle prestazioni, nonché garantire che le funzionalità di tipo real-time non possano essere negativamente impattate dalla presenza di quelle non real-time. Questo semplice esempio è sufficiente per chiarire quale sia il livello di complessità introdotto da queste architetture eterogenee, che hanno dato vita ad una categoria completamente nuova di sfide, legate alle problematiche di sviluppo, di debugging e di ottimizzazione di un sistema multicore. Lo strumento chiave, necessario per consentire agli sviluppatori di gestire le numerose nuove sfide associate agli ambienti multicore eterogenei, tra le quali le principali sono il boot sia del sistema che dei core remoti del processore e le funzioni di Ipc (Inter-Processor Communication), è costituito da un framework multicore completo.
Gestione remota del ciclo di vita del processore
Con Remote Processor Lifecycle Management, cioè la gestione remota del ciclo di vita del processore, si intende la capacità di assumere il controllo di un core remoto, nonché di avviare o arrestare un Sistema Operativo (o uno stack di applicazioni) residente su quel core remoto. Nella comunità Linux è stato adottato un apposito framework per il controllo remoto dei processori, concepito per la corretta gestione di questo tipo di scenario all’interno di un ambiente open source; ora Mentor ha incluso questo tipo di tecnologia all’interno del proprio ambiente framework multicore. La funzionalità RemoteProc di Mentor consente di implementare meccanismi di interoperabilità tra numerosi distinti sistemi operativi, come ad esempio Mentor Embedded Linux o l’Rtos Nucleus, e persino ambienti di tipo “bare metal”. Si possono immaginare alcuni interessanti esempi di utilizzo di questa capacità. In un primo scenario, il sistema potrebbe caricare e scaricare dinamicamente, a richiesta, sia OS che applicazioni su diversi core remoti, in base alle esigenze del momento; in tal modo un dispositivo può manifestare il possesso di un ampio spettro di funzionalità, pur rimanendo all’interno di un package relativamente ridotto. Un altro importante scenario d’uso è relativo alla gestione dei consumi; un processore remoto può essere mantenuto in uno stato di low-power mentre non è in uso, fattore che costituisce un requisito progettuale fondamentale per qualsiasi dispositivo alimentato a batteria.
Inter-Processor Communication
Dopo che il sistema operativo e lo stack di applicazioni del processore master sono stati avviati, il sistema può anche avere bisogno di comunicare con altre parti del dispositivo. In aggiunta alla funzionalità RemoteProc, il framework multicore di Mentor fornisce anche un’implementazione proprietaria, di tipo “cleanroom”, di una funzionalità open source di remote messaging fra processori, la quale consente di creare un canale di comunicazione tra il sistema operativo master e i sistemi operativi remoti, al fine di permettere ad ambienti proprietari, open source o bare metal di comunicare tra loro. In tal modo, è possibile trasferire dati in modo bidirezionale tra due core attraverso un canale di Ipc.
Ambienti operativi eterogenei
Se, da un lato, non esiste un singolo particolare approccio progettuale in grado di garantire una soluzione ottimale per qualsiasi scenario d’uso dei sistemi multicore, dall’altro è importante che gli sviluppatori si rendano conto che tali sistemi sono implicitamente molto diversi dagli ambienti di tipo single-core. I progettisti, mentre analizzano e pianificano il futuro dei propri dispositivi basati su ambienti operativi eterogenei, realizzati mediante sistemi SoC multicore eterogenei all’avanguardia, devono anche essere consapevoli di come i numerosi benefici siano controbilanciati da una realtà costellata di nuove complessità architetturali e implementative, spesso ancora inesplorate.
