Una Piattaforma di Servizi Applicativi o Asp (Application services platform) è una nuova classe di circuiti integrati formati da una Cpu, da un insieme standard di periferiche configurabili e da una matrice programmabile: il tutto in un unico dispositivo. Questi nuovi dispositivi combinano la programmazione logica con la programmazione software e offrono ai progettisti la massima flessibilità, consentendo di sviluppare rapidamente funzionalità per qualsiasi applicazione stiano servendo. Allo stesso tempo, la combinazione di Hw e di Sw in un unico dispositivo solleva molti interrogativi riguardo al modello di utilizzo. Per fortuna, l’avvento dell’Asp non significa che si debbano cambiare il modello di programmazione software, i processi e i tool. Quando sono realizzati su standard industriali, gli Asp forniscono un modello di programmazione identico a quello dei dispositivi a funzione fissa.
Piattaforme estensibili di elaborazione
Esaminiamo ora nella pratica un flusso Asp basato su standard industriali e sui flussi software standard: considereremo uno dei primi veri Asp, la famiglia di Piattaforme Estensibili di Elaborazione Zynq-7000 di Xilinx, annunciata di recente. Il diagramma a blocchi dell’EPP Zynq-7000, un dispositivo Asp realizzato attorno a un core Mpu Arm duale e basato su un’architettura di sviluppo con funzionalità che possono essere estese usando le risorse di logica programmabile del dispositivo: Xilinx lo ha realizzato in tecnologia di processo al silicio da 28nm, per raggiungere livelli straordinari di consumi/prestazioni/costi, a partire da meno di 15 dollari per ordinativi in grandi volumi. Diversamente dai precedenti Fpga dotati di processore, che richiedevano la programmazione dei blocchi logici dell’Fpga prima che si potesse addirittura attivare il processore su scheda, il nuovo dispositivo sfrutta un approccio che assegna la precedenza al processore, in cui il processore guida le danze e si attiva sin dall’accensione del dispositivo. Questo Asp particolare è dotato di un processore applicativo che fornisce un MPcore duale Arm CortexA9 con unità Neon Simd e a virgola mobile. Ogni core è dotato di 32 kbyte di cache I e D separate, oltre ad una cache unificata di Livello 2 da 2512 kbyte. I core di Cpu possono funzionare in modalità multiprocessore asimmetrica o simmetrica, o anche come una Cpu singola con l’altro processore disattivato per ridurre i consumi. Un controllore Dram integrato supporta i formati Ddr3, Ddr2 o Lpddr2, mentre un insieme di controllori flash gestisce la memorizzazione in fase di avvio e di configurazione. Il dispositivo include anche numerose periferiche. Il sistema di elaborazione presenta il proprio gruppo di I/O con pin dedicati per la Dram e un I/O multiplexato per le periferiche e per i dispositivi flash. Diversamente dagli Assp, i progettisti possono usare l’I/O della logica programmabile dell’Asp per collegare completamente l’insieme di periferiche, se questo è quanto è richiesto dall’applicazione finale. Il sistema di elaborazione - e in realtà l’intero dispositivo - è realizzato su standard di interfaccia Arm Amba, con un’interconnessione ad alta velocità di tipo interruttore a matrice. Xilinx ha mappato i registri su memoria, specialmente quelli per le periferiche integrate, e ha collegato l’intero sistema di elaborazione alla logica programmabile usando l’insieme di interfacce Axi, che supportano le funzioni di controllo, i dati e la memoria. Inotre, il dispositivo è dotato di una porta Acp (Accelerator Coherency Port), per consentire ai progettisti di aggiungere ai propri sistemi degli acceleratori coerenti con la cache, se fosse necessario.
Le sfide nella programmazione
Per essere una soluzione autosufficiente, un Asp deve risolvere le seguenti sfide nella programmazione: modello di programmazione, configurazione del sistema di elaborazione, configurazione della logica programmabile, avvio, librerie per accedere alle funzioni uniche di tipo hardware e a livello di sistema, gestione dell’alimentazione, sviluppo del pacchetto di supporto alla scheda, supporto al sistema operativo, supporto alla ricerca errori, tool di sviluppo software.
Modello di programmazione - Innanzitutto, gli Asp devono prevedere un modello di programmazione robusto e semplice all’uso: nel caso dei dispositivi Zynq-7000, il modello è basato sull’insieme ben collaudato di istruzioni Cpu di Arm. Di conseguenza, gli stessi tipi di chiamate mappate in memoria, effettuate verso le risorse all’interno del sistema di elaborazione, sono identici per la funzionalità estesa specifica di un’applicazione che viene aggiunta alla logica programmabile. Questo aspetto è molto importante perché, per fare sì che il software usi le estensioni in modo efficace, queste devono essere un insieme ben noto e sistematico di interfacce. Ciò aiuta inoltre i progettisti a creare insiemi di funzioni che possono essere realizzate su software, su hardware o su entrambi. I progettisti possono anche creare una libreria di funzioni software e di funzioni IP hardware che condividono un’interfaccia comune di programmazione. Poiché questi dispositivi e le rispettive funzioni sono realizzati in base a standard comuni, i fornitori terzi possono anche creare funzioni software e IP hardware, sia di uso comune, sia specifiche per un’applicazione, offrendo vantaggi per l’intero mercato. Per essere un Asp autosufficiente, il dispositivo deve essere dotato di core di Cpu altamente flessibili. La multiprogrammazione asimmetrica dovrebbe supportare l’uso di ambienti di esecuzione diversi sui vari core, sia monitorati, sia non monitorati, attraverso gli hypervisor. Il supporto all’elaborazione simmetrica, specialmente attraverso gli OS, fornisce nel complesso una spinta alle prestazioni di elaborazione e può rimuovere gran parte della complessità di sviluppo dell’applicazione, legata al progetto multicore. Un Asp dovrebbe anche supportare l’utilizzo in modalità a core singolo per applicazioni che non richiedono o non possono trarre vantaggio dall’uso di più Cpu. Supportando l’uso eterogeneo delle Cpu, è possibile fornire su un’unica piattaforma lo spettro di soluzioni che comprende il core singolo e il core multiplo, consentendone l’uso specifico per un’applicazione dell’architettura di elaborazione.
• Configurazione del sistema di elaborazione - Gli Asp dovrebbero anche consentire agli utenti di configurare la funzionalità dello stesso sistema di elaborazione. Questi dispositivi permetteranno ai progettisti di impostare il tipo di Ddr che desiderano sia usata dal dispositivo, oltre alle periferiche, ai relativi I/O multiplexati e all’ampiezza delle interfacce fra il controllore di memoria e la logica programmabile. Durante il funzionamento, gli utenti possono inoltre accedere a un insieme più ridotto di funzionalità per variare, ad esempio, l’arbitraggio o la priorità sul controllore di memoria, per adattarsi a schemi di traffico specifici. Per semplificare l’impostazione di tutte queste opzioni, i produttori di Asp devono fornire un tool di configurazione che produca la documentazione sulla configurazione per l’uso nello sviluppo hardware e software. Questi tool devono anche generare file di dati leggibili dall’uomo, che i tool a valle useranno direttamente, che saranno modificati manualmente o che saranno usati per gestire ambienti di realizzazione basati su script.
• Configurazione della logica programmabile - Oltre ad essere in grado di programmare il sistema di elaborazione dell’Asp, un dispositivo Asp, per definizione, consente agli utenti di scaricare le funzioni verso la logica programmabile. Per rendere il sistema accessibile a un’ampia varietà di utenti, la configurazione della logica programmabile dovrebbe essere sotto il controllo del sistema di elaborazione.
Idealmente, il sistema di elaborazione non dovrebbe richiedere che la logica programmabile sia configurata in fase di avvio. Piuttosto, questa sarebbe una scelta che il progettista effettua in base alle esigenze della propria applicazione di riferimento. Ciò consente al sistema di elaborazione di caricare una configurazione in base ai parametri determinati dopo l’avvio. Un Asp di prim’ordine dovrebbe anche supportare la riconfigurazione dinamica parziale, una tecnologia analoga a quella di carico e scarico dinamico dei moduli software. Il sistema di elaborazione è in grado di riconfigurare una porzione della logica programmabile per un carico, ad esempio, in un nuovo insieme di parametri di algoritmo o persino in una funzione completamente nuova, richiesta in un particolare momento. Inoltre, le informazioni sulla configurazione per la logica programmabile dovrebbero supportare la cifratura e l’autenticazione per proteggere la proprietà intellettuale. Questo è importante non solo per i blocchi personalizzati di proprietà intellettuale, ma anche per la proprietà intellettuale acquistata da terzi.
• Avvio - Gli Asp dovrebbero presentare una funzione multistadio di avvio che consenta agli utenti di adattare l’avvio alle proprie applicazioni specifiche. Gli utenti dovrebbero anche essere in grado di selezionare un dispositivo di avvio attraverso dei piedini di selezione della modalità o attraverso un altro meccanismo. Una Rom di avvio dovrebbe supportare la modalità di funzionamento sicura e quella non sicura, incluse la decifratura e l’autenticazione. In seguito alla Rom di avvio, l’avvio definito dall’utente dovrebbe consentire di caricare ulteriori immagini di avvio, non solo dai dispositivi flash, ma anche da qualsiasi periferica adatta allo scopo, come le interfacce Ethernet, Usb o SD. La configurazione della logica programmabile dovrebbe essere un processo parallelo che può essere avviato anche durante questa fase. Il funzionamento ridotto in base ad un’immagine completamente testata, sia per l’avvio del sistema di elaborazione, sia per l’immagine della logica programmabile, fornisce un meccanismo di ripristino nel caso in cui un’immagine sia danneggiata, ad esempio durante un aggiornamento remoto sul campo. Per un Asp, operazioni di questo tipo comportano degli aggiornamenti non solo di tipo software, ma anche a livello di hardware. La capacità di combinare le due immagini è molto importante per le realizzazioni che lo richiedono. Un tool che combini queste immagini in una singola immagine flash consente di semplificare la programmazione della memoria flash e riduce il numero di file di dati richiesti nella gestione dei dati di prodotto.
• Librerie di funzioni uniche - Qualsiasi funzione di tipo hardware o a livello di sistema dovrebbe essere dotata di un’interfaccia di programmazione per un’applicazione. Le Api semplificano la programmazione fornendo un insieme definito di funzioni software che accedono all’hardware disponibile e alle risorse del sistema. Un esempio, in questo contesto, è dato dalla configurazione dinamica della logica programmabile. Dovrebbe esistere un insieme di funzioni Api per rendere questa capacità prontamente disponibile per essere usata dall’applicazione software.
• Gestione dell’alimentazione - Analogamente, gli Asp dovrebbero includere funzionalità che consentano agli utenti di gestire l’uso di energia del dispositivo o persino del sistema. Inoltre, essi dovrebbero essere in grado di fare ciò attivando dei compromessi all’interno del sistema di elaborazione e della logica programmabile. Questo può coprire delle capacità come la possibilità di disattivare la logica programmabile, di rallentare i clock o di mettere lo stesso sistema di elaborazione in modalità di sospensione e di riattivarlo attraverso un segnale Lan o Can.
• Sviluppo del codice di supporto alla scheda - I dispositivi Asp aiutano a colmare il divario che esiste fra i dispositivi a funzione fissa e i dispositivi completamente programmabili, come i processori sintetizzabili su Fpga, per quanto riguarda lo sviluppo del codice di supporto alla scheda (BSP). Con i dispositivi a funzione fissa, i fornitori di sistemi operativi sono in grado di fornire un BSP che supporta tutte le funzionalità del dispositivo. Usando tali dispositivi, gli utenti possono adattare queste caratteristiche ad una realizzazione specifica. Con una soluzione completamente sintetizzabile, i produttori forniscono dei BSP a funzione fissa solo per riferimento, dato che pressoché ogni realizzazione fa uso di un insieme diverso di periferiche e di altre funzionalità. Di conseguenza, una grande maggioranza di queste ultime richiedono un BSP su misura. Nel campo della progettazione si è cercato di sviluppare delle tecnologie per la generazione dinamica dei BSP, allo scopo di semplificare questo compito, ma l’uso di architetture proprietarie di un produttore per quanto riguarda l’insieme di istruzioni ha limitato l’adozione di questa tecnologia. Con i dispositivi Asp, i produttori possono fornire dei Bsp a funzione fissa che supportano l’intero sistema di elaborazione. Dato che il modello di programmazione è coerente fra il sistema di elaborazione e la logica programmabile, lo sviluppo del Bsp per la parte personalizzata può fare uso delle librerie di driver del dispositivo per disporre di un insieme più ampio di blocchi di proprietà intellettuale standardizzati per l’interfaccia. I progettisti, i produttori di dispositivi o i fornitori terzi di proprietà intellettuale possono sviluppare librerie di blocchi sintetizzabili di proprietà intellettuale con dei driver che gli utenti possono aggiungere, a loro volta, ad un Bsp.
Supporto al sistema operativo
Gli Asp devono supportare i sistemi operativi standard. Infatti, le architetture Arm godono di ciò che è senza dubbio il più ampio supporto fra i produttori di Rtos e di sistemi operativi e anche fra i fornitori di sistemi operativi in tempo reale come Linux. Di conseguenza, in genere la disponibilità di porte del kernel non costituisce un problema. Piuttosto, la questione verte generalmente sulla disponibilità di un Bsp. Come discusso in precedenza, i dispositivi Asp possono essere piuttosto supportati come dispositivi a funzione fissa, con le librerie disponibili per supportare le estensioni all’interno della logica programmabile.
Supporto alla ricerca errori
Con l’aumentato della complessità e con l’integrazione di più funzionalità all’interno dei dispositivi, durante la fase di sviluppo si passa sempre più tempo nei cicli di ricerca errori. Di conseguenza, un Asp autosufficiente deve includere un’infrastruttura robusta per la ricerca e la correzione degli errori, che sia in grado di fornire più controllo e visibilità sui meccanismi di funzionamento interni dei dispositivi. Arm fornisce un’infrastruttura di questo tipo, usando la proprietà intellettuale CoreSight per la ricerca e la correzione degli errori e per la tracciabilità. È importante assicurare la tracciabilità su chip usando solo pochi kilobyte di memoria, specialmente per l’analisi dei guasti sul campo, in cui non sono disponibili i piedini per la tracciabilità per la raccolta dei dati all’esterno del chip. I piedini per la tracciabilità dovrebbero essere disponibili come opzione, di modo che gli utenti possano recuperare risorse preziose in termini di piedini disponibili, una volta che il prodotto è in produzione. Per i progetti multicore, CoreSight consente di avere visibilità sull’esecuzione del programma ed è adattabile al sistema operativo. Lo standard CoreSight offre il supporto ai tool per Jtag e per la tracciabilità, di modo che i tool da più produttori possano supportare un’ampia varietà di dispositivi basati su core Arm forniti da più produttori. Una funzionalità incorporata di analizzatore logico, che sia in grado di attivare e di catturare eventi e dati, fornisce visibilità all’interno della logica programmabile. Dovrebbero esistere dei segnali fra l’IP CoreSight e la logica programmabile, che consentano l’attivazione incrociata fra i due domini. Le soglie impostate nel software di ricerca errori dovrebbero attivare la funzione di cattura dell’analizzatore logico integrato, mentre i punti di attivazione impostati nell’analizzatore logico possono interrompere la funzione di ricerca errori. Questa attivazione integrata su chip fa sì che la funzione di ricerca errori e l’analizzatore logico siano mantenuti in stretta sincronizzazione, e assicura che la cattura dei dati sia molto più semplice da correlare. Gli utenti possono anche creare blocchi di proprietà intellettuale personalizzati e aggiungerli alla logica programmabile per aumentare il controllo, la visibilità e l’efficacia di cattura.
• Tool di sviluppo software - I tool di sviluppo software per gli Asp devono avvalersi di strumenti che gli sviluppatori di software usano già, dai tool a linee di comando agli ambienti integrati di sviluppo. Lo sviluppo alle architetture Arm da parte dei sistemi operativi è già ampiamente disponibile, così anche il supporto ai tool da parte dei produttori di sistemi operativi e di altri. Le opzioni open-source, come ad esempio Gnu, sono ben supportate e disponibili. Il componente critico per i tool software è l’ottenere le informazioni su come il sistema di elaborazione sia configurato, sulla mappa di memoria, sulle funzioni che risiedono nella logica programmabile e sui parametri di avvio. Il tool di configurazione dovrebbe fornire queste informazioni per il tool di sviluppo software, in un formato leggibile dall’uomo e modificabile, per poterle adattare all’interno dell’ambiente di sviluppo specifico che il team di sviluppo software sta usando. I dispositivi Asp che stanno ora comparendo sul mercato presentano una piattaforma vantaggiosa per rispondere a una varietà di sfide nello sviluppo e nell’impiego dei prodotti. Questi dispositivi sono ibridi, nel senso che forniscono una capacità di sviluppo fissa ma espandibile. Tuttavia, quando sono opportunamente realizzati con un’architettura basata sugli standard disponibili, possono sfruttare quanto esiste già, aprendo allo stesso tempo nuovi spazi applicativi e nuove opportunità. L’intera piattaforma, specialmente nella programmazione, deve essere ben considerata e gestita di modo da consentire a un ampio numero di utenti di adattare facilmente la tecnologia, per realizzare una varietà di prodotti potenti e innovativi. L’obiettivo deve essere una piattaforma completa. Questo è stato l’approccio adottato per la Piattaforma Estensibile di Elaborazione Zynq-7000 di Xilinx.
