Sviluppo SoC Software-Driven

• 
• Tweet
• Pin It
• Condividi per email

Nel settore dei semiconduttori, è noto che i costi di sviluppo software per un nuovo SoC superano sempre più i costi di sviluppo hardware.

Questo sostanziale incremento dei costi del software è una realtà ormai consolidata, e la necessità di ridurre, o almeno controllare, questi oneri ha portato a un punto di svolta per quel che riguarda la capacità degli strumenti e delle tecniche di sviluppo utilizzate per realizzare SoC complessi.

Fig. 1 – Confronto tra flussi di sviluppo del software per dispositivi SoC

L’attuale metodologia di sviluppo spesso non è adatta alla creazione di SoC “software-intensive” destinati a smartphone, tablet e altre applicazioni che devono soddisfare obiettivi di time-to-market e di costo sempre più severi.

Il problema più rilevante sta nel fatto che, nell’ambito del processo di progettazione, il software viene spesso sviluppato in ritardo (in alcuni casi addirittura successivamente al silicio), anche se il software ha un impatto significativo sulle prestazioni complessive e sulle funzionalità del SoC.

La figura 1 riporta questo tipo di flusso di sviluppo. Nel flusso SoC tradizionale, lo sviluppo del software segue lo sviluppo hardware e le attività di verifica del codice applicativo sono implementate solo quando è disponibile il silicio. Questo approccio, che prevede un allungamento del il time-to-market del SoC, costituisce oggi probabilmente più un’eccezione che una regola.

Negli ultimi dieci anni circa, sono stati compiuti grossi sforzi per trasferire le attività di sviluppo software nel dominio pre-silicio. Ciò è stato possibile grazie all’utilizzo di soluzioni quali le piattaforme virtuali software, gli ambienti di prototipazione FPGA e le funzioni di emulazione hardware. Per molte aziende di semiconduttori, questo flusso SoC “software-enhanced” rappresenta una prassi corrente (si faccia sempre riferimento alla Fig. 1).

Benché si sia cercato di anticipare lo sviluppo del software, la quantità di codice da eseguire prima di disporre del silicio è aumentata in maniera esponenziale, spesso compromettendo i progressi compiuti. Il motivo è evidente.. La disponibilità di sistemi operativi sempre più potenti (per esempio iOS di Apple) e di software open source (come Linux e Android), ha favorito uno sviluppo dei dispositivi consumer che era difficile da prevedere.

Il ruolo della “Legge di Moore”

Grazie alla crescente disponibilità di transistor, i progettisti di silicio possono integrare un numero sempre maggiore di processori multicore e di sottosistemi hardware, dedicati per esempio alla grafica, all’elaborazione video e alle comunicazioni wireless.

Questi blocchi hardware, a loro volta, richiedono un supporto di stack software che permetta di sfruttarne appieno le funzionalità. Quindi si ha a che fare con un software di sistema potente e pervasivo, da adattare e ottimizzare in tempi sempre più ridotti a un hardware SoC contraddistinto da prestazioni sempre maggiori.

Il problema, tuttavia, è che tutti i sistemi operativi implicano ormai grandi quantità di istruzioni. Per sviluppare, testare e ottimizzare il codice dipendente dalla piattaforma SoC, il team di progettazione software deve fare girare centinaia di megabyte di “immagini” eseguibili.

Lavorare in ambienti di simulazione o di emulazione a 10 kHz non rappresenta certamente una soluzione efficace nel momento in cui risulta necessario far girare miliardi di istruzioni necessarie per caricare Android ed effettuare il debug dell’ambiente operativo o dell’applicazione del SoC in fase di sviluppo.

Benché l’emulazione eseguita a velocità dell’ordine dei MHz dell’emulazione rappresenti una soluzione di compromesso, l’avvio completo di Linux, Android o iOS può richiedere ancora delle ore. La prototipazione basata su FPGA assicura velocità di esecuzione più elevate (dell’ordine delle decine di MHz) a fronte di una minore accuratezza del debug hardware rispetto alla simulazione o all’emulazione. Oltre a questo, il prototipo FPGA si rende disponibile solo nella fase avanzata del progetto, cioè quando la descrizione dell’hardware è sufficientemente matura.

L’esigenza di eseguire imponenti stack software comporta una pressione molto forte sulle tecnologie di sviluppo SoC, in particolare piattaforme virtuali, ambienti di prototipazione FPGA ed emulatori hardware. Tali soluzioni sono chiamate ad aumentare la loro capacità di esecuzione del codice, tutelando contemporaneamente la fedeltà e la visibilità rispetto all’hardware in fase di sviluppo. I vincoli o i limiti imposti agli sviluppatori di software SoC, nell’esecuzione e nell’analisi di grandi quantità di codice in anticipo sulla disponibilità del silicio, influiscono negativamente sulla loro produttività, aumentando i costi e i ritardi di time to market.

Idealmente, si dovrebbe arrivare al flusso SoC Software-Driven mostrato nella parte alta della figura 1, dove vi è una sostanziale continuità di sviluppo tra hardware e software utilizzando in tutti i punti del flusso la migliore rappresentazione hardware disponibile. A questo si aggiunge una significativa velocità di esecuzione, adeguata per fare girare Android, Windows RT e altri diffusi sistemi operativi.

Il flusso SoC software-driven definisce una metodologia che utilizza nuovi strumenti e nuove tecnologie di sviluppo. Esso permette non solo di definire e verificare con ampio anticipo il software di sistema, ma anche di utilizzarlo per verificare l’hardware già dalle prime fasi del ciclo di progettazione (verifica software-driven). I progettisti possono inoltre valutare e correggere le interazioni hardware/software, controllando e ottimizzando il codice fornito al cliente del SoC (per esempio, Android trasportato e ottimizzato per il SoC in fase di sviluppo). Ciò permette di rispettare l’enfasi sull’esecuzione del software in tutte le fasi di sviluppo dell’hardware SoC.

La produttività software e i suoi limiti

Aumentare la produttività software è un compito impegnativo. Quando si punta a migliorare la produttività dello sviluppatore di software SoC, è necessario sapere a cosa si va incontro e fornire dei miglioramenti significativi.

Un testo classico, di Frederick Brooks (“No Silver Bullet – Essence and Accident in Software Engineering”), divide le difficoltà associate allo sviluppo software in due componenti: incidentali e sostanziali. La difficoltà incidentale è legata alla trasformazione della rappresentazione concettuale del software in una entità eseguibile (correttamente) su una particolare piattaforma hardware. Un grande passo avanti nella produttività software è stato l’introduzione dei linguaggi di alto livello, che automatizzano il processo di trasformazione.

Ciò che rimane è la difficoltà sostanziale. La tesi di Brook è che nessuno strumento destinato a risolvere delle difficoltà sostanziali, potrà mai apportare un miglioramento di produttività paragonabile a quello ottenuto con l’introduzione dei linguaggi di alto livello.

Tuttavia, Brooks non è del tutto pessimista. Egli raccomanda di considerare il compromesso “make/buy” come potente leva per aumentare la produttività. Evitare agli sviluppatori di scrivere software di cui non c’è bisogno, è un ottimo modo per renderli molto più produttivi.

Un altro approccio per affrontare le difficoltà incidentali è di ridurre drasticamente i tempi di “turnaround” legati all’individuazione dei difetti, alla loro eliminazione e al collaudo della correzione. L’ovvia implicazione per lo sviluppo, pre-silicio, del software per SoC è di avere un ambiente di esecuzione abbastanza veloce per lavorare in maniera interattiva, o dei processi che durino pochi minuti anziché ore o giorni.

Quando si lavora per aumentare la produttività degli sviluppatori di software per SoC, sono necessari approcci che apportino benefici considerevoli e facilmente misurabili. In cima alla lista delle soluzioni si trova un flusso di sviluppo che permetta di evitare le difficoltà incidentali legate alla lentezza dell’esecuzione del software. Ciò è possibile attraverso una tecnologia che garantisca un “significativo” miglioramento a livello di esecuzione del software sulla migliore rappresentazione hardware disponibile e più in anticipo possibile nell’ambito del ciclo di sviluppo.

Lo sviluppo del software è fortemente dipendente dall’hardware

Il dibattito tra gli sviluppatori di software all’interno delle aziende di semiconduttori, ha messo in luce un quadro piuttosto chiaro. Per gli sviluppatori software, ironia della sorte, l’ostacolo principale risiede nell’hardware. Tutto lo sforzo legato allo sviluppo software – dalla scrittura dei driver di basso livello alle app Android multimediali più complesse – è pilotato e limitato dall’hardware SoC sottostante e dalla sua effettiva disponibilità.

Fig. 2 – Stack software e blocchi hardware SoC complessi

Occorre tenere a mente, tuttavia, che gli sviluppatori software stanno indirizzandosi verso sistemi operativi, quali Android, Linux e Windows RT, con milioni di linee di codice e megabyte di immagini eseguibili. A tale proposito è estremamente importante che l’ambiente di sviluppo SoC sia in grado di gestire i requisiti prestazionali richiesti per eseguire tali sistemi operativi – grandi e potenti – garantendo contemporaneamente una rappresentazione accurata dell’hardware sottostante.

La figura 2 illustra un tipico progetto complesso completo dei suoi componenti hardware e software. L’hardware SoC è composto da un mix di blocchi, alcuni specifici, altri basati sul riutilizzo di SoC di generazione precedente, altri ancora acquistati sotto forma di IP e così via.

Ogni produttore di SoC deve decidere dove investire le proprie risorse. In alcuni casi essi ritengono di poter dare un contributo sostanziale su tutto il SoC, in altri possono decidere di concentrarsi su un sottosistema hardware particolarmente importante, utilizzando – per la parte restante del progetto – blocchi commerciali standard.

La maggior parte di questi blocchi hardware si interfaccerà col processore applicativo. Per permettere a ogni blocco hardware del SoC di lavorare efficacemente, il software del processore applicativo dovrà pertanto utilizzare driver e altri strumenti di supporto, compresi degli adattamenti del kernel del sistema operativo e del middleware.

Si noti inoltre che alcuni dei blocchi stessi sono processori (nel caso dell’esempio in esame, un DSP), che ovviamente girano su uno stack software sofisticato.

La figura 3 (a sinistra) mostra una panoramica più dettagliata degli stack software più comuni in un SoC.

Una situazione potenzialmente preoccupante che emerge dalla figura 3, è legata al fatto che una quantità significativa del valore del progetto è legata al software che gira sul SoC, parte del quale deve essere sviluppato da zero (blocco contrassegnato con Proprietary OS).

Questo porta in un vicolo cieco, limitando le possibilità di aumentare la produttività di sviluppo software. La buona notizia è che, spesso, il software necessario per un SoC è di provenienza esterna, per esempio Android di Google. In tale contesto l’impegno nello sviluppo del software da parte del produttore di SoC è limitato al porting e all’ottimizzazione necessaria per sfruttare le capacità specifiche del progetto.

Quindi, qualsiasi aumento riscontrato dallo sviluppatore del SoC in termini di costi software, non sarà legato allo sviluppo di Android, ma agli oneri di adattamento di Android al proprio SoC. A parte il sottrarre transistor ai progettisti hardware, è difficile vedere altre possibilità per ridurre drasticamente i costi. Tuttavia, è possibile ridurre drasticamente il time to market anticipando lo sviluppo di parti significative di codice nelle prime fasi del flusso di progettazione.

Come mostrato in Figura 3, i progettisti non sviluppano solo il software che viene fornito col SoC. Infatti il prodotto richiede la definizione di una quantità significativa di programmi di test e verifica, da utilizzare insieme ad altri strumenti più tradizionali di verifica hardware.

Non è raro che, come sistema operativo di “test” per un nuovo SoC, venga utilizzato Linux. L’ambiente Linux mette a disposizione un ricco set di strumenti e funzionalità, che semplificano notevolmente l’esecuzione del software di verifica. Non vi è però alcuna certezza del fatto che Linux venga poi fornito al cliente: il suo utilizzo può essere puramente interno.

In questo caso si tratta di una verifica software-driven, soggetta alle stesse specifiche e requisiti prestazionali (se non ancora più stringenti) dello stack software del SoC fornito al cliente.

Si noti che Linux, Android, Windows RT e altri sistemi operativi commerciali sono sviluppati al di fuori del settore dei semiconduttori. In questi casi, lo sforzo del produttore del SoC è rivolto in larga misura al porting e all’ottimizzazione del software, modificato per lavorare al meglio sul dispositivo in fase di sviluppo.

Tale sforzo non si limita, come molti possono pensare, ai livelli più bassi dello stack, ad esempio driver delle periferiche. Anche se le dipendenze dall’hardware vengono spesso delegate ai driver, in molti casi è necessario apportare delle modifiche al sistema operativo o al middleware per sfruttare a fondo le capacità hardware del SoC.

Che si tratti di software fornito con il SoC o di software utilizzato solo internamente per scopi di test, per sviluppare e testare il sistema operativo, il software hardware-dipendente e l’hardware stesso, non c’è modo per evitare che l’OS sia caricato, carichi il middleware e supporti l’esecuzione delle applicazioni.

Lo sviluppo software-driven supporta lo sviluppo hardware

È interessante osservare che più si risale nel processo di sviluppo hardware, più questo assomiglia allo sviluppo software, mutuando problemi e soluzioni tipiche di questo mondo. Possiamo notare che quanto più la progettazione hardware si configura in modo simile allo sviluppo software, tanto più sono limitati gli incrementi di produttività, esattamente come avviene nel caso del software puro.

Come nel caso del software, il modo migliore per aumentare l’efficienza di uno sviluppatore hardware è quello di non sviluppare hardware inutile. In tale contesto i progettisti SoC hanno da tempo capito l’importanza del riutilizzo dell’IP, sia essa di provenienza interna o acquistata esternamente. Quindi, non sorprende che gli sviluppatori di hardware SoC abbiano sempre privilegiato il riutilizzo o l’acquisto di IP per limitare la quantità di nuovo “software” (cioè di hardware SoC da sviluppare da zero) e l’uso di strumenti di sintesi di alto livello e di altri mezzi per aumentare il livello di astrazione. La figura 2 mostra i numerosi blocchi IP che compongono un SoC moderno.

Una lezione proveniente dal mondo software, prevede l’aumento del livello di astrazione utilizzato per implementare i nuovi blocchi SoC. Poiché il livello di astrazione del linguaggio RTL utilizzato dallo sviluppatore hardware è assimilabile al livello di astrazione del linguaggio assembly utilizzato dallo sviluppatore software, passare a strumenti di sintesi in SystemC e a tool come C to Silicon di Cadence, permette di accedere immediatamente a un livello superiore.

L’utilizzo di blocchi software-intensive basati su processore rappresenta un altro approccio. In questo caso, la maggior parte dell’implementazione a livello hardware di una funzione rimane confinata nel software. Tale software è scritto in C o C + + ed è eseguito su un processore specializzato, costruito e ottimizzato per eseguire la funzione del blocco a velocità pressoché RTL. Il core Tensilica Xtensa di Cadence e ARC di Synopsys sono buoni esempi di questo approccio.

Rifacendoci al concetto di Brooks, è possibile anche osservare come nel mondo EDA “classico” gli strumenti continuino ad aumentare la produttività degli sviluppatori tenendoli allineati alle evoluzioni delle tecnologie di processo.

In effetti, per i semiconduttori, le attività di back-end (place and route, timing closure e così via) sono dominate da difficoltà incidentali, cioè dai cambiamenti fisici risultanti dal passaggio al nodo tecnologico successivo. Come sostiene Brooks, le difficoltà incidentali sono superabili con strumenti più idonei per ottenere incrementi di produttività radicali: l’industria EDA si ispira continuamente a questo concetto, sviluppando su base continua i propri strumenti, anno dopo anno.

Dove lo sviluppo SoC è dominato dalla fisica – per esempio nel place and route, nel timing closure e in altri aspetti incidentali – gli sforzi di ingegneria continueranno a garantire aumenti di produttività. Dove invece lo sviluppo hardware è dominato da difficoltà inerenti, l’aumento di produttività può essere garantito dal riutilizzo o dall’acquisto di IP.

Fig. 3 – Stack software e flusso SoC software-driven

Alla fine, poiché sempre più hardware viene ricondotto a livello software (sia che si tratti delle prime fasi del ciclo di progettazione, sia che si tratti di un approccio processor-based permanente), l’esecuzione del codice durante il processo di sviluppo assume un’importanza crescente anche dal puro punto di vista hardware. Tale processo rafforza ulteriormente la “value proposition” del flusso SoC software-driven, accelerando il time-to-market e riducendo i costi.

Flusso complessivo per lo sviluppo SoC Software-Driven

Il lato destro della figura 3 mostra una rappresentazione del flusso software-driven e la sua relazione con il software di un SoC tipico di un dispositivo mobile. Piattaforme virtuali, emulazione e FPGA di prototipazione (e il silicio stesso) concorrono tutti a fornire ambienti di esecuzione software adatti per le varie fasi del ciclo di sviluppo SoC.

Un aspetto critico del flusso SoC software-driven è che una percentuale enorme dei milioni di istruzioni eseguite al boot di Android, coinvolge solo un piccolo sottoinsieme dell’hardware SoC, principalmente il processore e la memoria.

Il flusso SoC software-driven sfrutta questa situazione spostando questi elementi in ambienti di simulazione più rapidi (anche se meno precisi) collegati. Ad esempio, un Fast Model ARM è spostato fuori dall’ambiente di -emulazione insieme alla sua memoria. Questo approccio “ibrido” è accuratamente ingegnerizzato per interagire perfettamente con il resto dell’RTL del SoC, che continua ad essere eseguito in emulazione o in un sistema di prototipazione FPGA.

Non esistono due progetti SoC uguali, pertanto è sempre necessaria una messa a punto della configurazione. E, in alcuni casi, nel corso del tempo, vari sottosistemi hardware possono essere spostati dall’emulazione RTL a un ambiente di esecuzione più veloce, in cui la precisione di emulazione è meno importante della velocità di esecuzione del software.

Idealmente, gli stessi strumenti (debugger e così via) funzionano nell’ambito dei diversi ambienti, permettendo agli sviluppatori software e ai loro partner hardware, di scegliere il punto più adatto del flusso dove affrontare adeguatamente le attività di sviluppo.

Jim Ready, Cadence Design Systems

• 
• Tweet
• Pin It
• Condividi per email