Co-design hardware/software

Il co-design hardware/software (spesso abbreviato in co-design HW/SW) è una metodologia di progettazione a livello di sistema in cui i componenti hardware e software vengono sviluppati insieme anziché separatamente. Il suo obiettivo è migliorare le metriche a livello di sistema come le prestazioni, il consumo energetico, il costo e la flessibilità, provando diversi modi di suddividere le funzionalità tra hardware e software fin dalle prime fasi della progettazione.^[1][2]

Il co-design hardware/software è ampiamente utilizzato nei sistemi embedded,^[3] nei sistemi cyber-fisici,^[4] e nelle piattaforme di calcolo eterogeneo,^[5] dove l'esecuzione del software e l'accelerazione hardware devono operare in stretta collaborazione.^[3][6]

Il co-design hardware/software si basa sul principio che i vincoli hardware e software vengano considerati simultaneamente, in modo che le decisioni su un lato possano essere prese tenendo conto dell’altro. Una stessa funzione può essere implementata sia in software su un processore sia in logica hardware dedicata, con effetti congiunti su prestazioni, consumo energetico, area e costo. Mantenendo entrambi gli aspetti aperti nelle prime fasi della progettazione, il co-design consente di esplorare combinazioni che un approccio unilaterale non sarebbe in grado di individuare.^[1][2]

Nel co-design, il confine tra hardware e software è trattato come una variabile di progetto. Le operazioni computazionalmente intensive e regolari vengono tipicamente implementate in hardware dedicato, mentre la logica di controllo e le parti soggette a variazioni restano nel software. I parametri che definiscono questa suddivisione, come la larghezza dei bit, la dimensione dei buffer e il grado di parallelismo, sono condivisi tra i due domini invece di essere fissati separatamente.^[2][3][7]

Il co-design hardware/software prese forma alla fine degli anni ’80 e all’inizio degli anni ’90, quando i sistemi embedded stavano diventando sempre più complessi e la pratica tradizionale di progettare hardware e software separatamente iniziò a mostrare i propri limiti. Molti dei primi prodotti embedded, come apparecchiature per le telecomunicazioni, controllori industriali ed elettronica di consumo, presentavano vincoli stringenti di prestazioni e consumo energetico che non potevano essere soddisfatti ottimizzando il solo software.^[8]

Le prime ricerche esplorarono la possibilità di progettare congiuntamente hardware digitale e software embedded, in modo che una determinata funzione potesse essere implementata sia su un processore sia in logica hardware dedicata. In questo contesto furono sviluppati metodi formali per la partizione hardware/software, la specifica a livello di sistema e la stima delle prestazioni, mentre gli strumenti di automazione della progettazione elettronica (EDA) iniziarono a supportare flussi di progettazione integrati.^[1][2]

Nel corso degli anni ’90, il co-design si legò sempre più strettamente ai sistemi embedded e alla progettazione dei sistemi su chip (SoC). Con l’integrazione di processori, memorie, periferiche e logica personalizzata su un unico chip, la progettazione congiunta di hardware e software divenne essenziale per soddisfare i vincoli di costo, prestazioni e consumo energetico.^[8][9]

La crescente diffusione delle field-programmable gate array (FPGA) negli anni 2000 ampliò ulteriormente il campo di applicazione del co-design. A differenza degli application-specific integrated circuit (ASIC), le FPGA possono essere riprogrammate dopo la produzione, consentendo di modificare l’hardware insieme al software.[5] Gli strumenti di sintesi ad alto livello (HLS) ridussero ulteriormente la barriera d’ingresso, permettendo di tradurre in hardware digitale parti di programmi scritti in linguaggi ad alto livello come C e C++.^[10]

La crescente adozione delle field-programmable gate array (FPGA) negli anni 2000 ampliò ulteriormente il campo di applicazione del co-design. A differenza degli application-specific integrated circuit (ASIC), le FPGA possono essere riprogrammate dopo la produzione, quindi l'hardware può essere modificato insieme al software.^[11] Gli strumenti di sintesi ad alto livello (HLS) abbassarono ulteriormente la barriera consentendo di trasformare in hardware digitale parti di un programma scritte in linguaggi ad alto livello come il C e il C++.^[10]

Più recentemente, il co-design hardware/software è stato adottato nell’intelligenza artificiale (IA), nel cloud computing e nel calcolo eterogeneo. Gli acceleratori per IA, le architetture per data center e le architetture a dominio specifico possono essere progettati con approcci di co-design per aumentare le prestazioni per watt, mantenendo al contempo sotto controllo flessibilità e costi di sviluppo.^[5][12]

Le metodologie di sviluppo hardware/software sono comunemente descritte come uno spettro che va dallo sviluppo indipendente al co-design integrato.^[2][3]

Nel modello di progettazione tradizionale, hardware e software vengono sviluppati in larga misura in modo autonomo.^[2][3] Gli ingegneri hardware progettano una piattaforma in base a vincoli architetturali, mentre gli sviluppatori software scrivono le applicazioni assumendo che l’interfaccia hardware rimanga invariata. I due gruppi comunicano principalmente attraverso set di istruzioni, interfacce di programmazione o livelli di astrazione hardware predefiniti.^[13]

Dato che i due domini sono disaccoppiati, ciascuno può evolvere a proprio ritmo. Questo approccio funziona bene per piattaforme di calcolo general-purpose, software desktop, sistemi operativi e hardware commerciale standard, dove una singola piattaforma deve supportare un’ampia gamma di programmi eterogenei.^[13]

Un limite di questo modello è che la separazione tra hardware e software riduce le possibilità di ottimizzazione trasversale tra i livelli. Il software non può sfruttare capacità hardware non presenti nel dispositivo, mentre l’hardware non può essere adattato al comportamento di applicazioni specifiche.^[2][3]

Un approccio comune consiste nello scegliere prima l'hardware, per poi ottimizzare il software allo scopo di estrarne le massime prestazioni. L'hardware è trattato come fisso e gli sviluppatori adattano i propri algoritmi e il proprio codice per fare il miglior uso delle risorse disponibili.^[2][3]

Le tecniche tipiche includono ottimizzazioni del compilatore, vettorizzazione, buon utilizzo della cache, programmazione parallela, e un'organizzazione ottimizzata delle strutture dati in memoria.^[13] Inoltre, gli algoritmi possono essere riscritti per utilizzare istruzioni single istruction, multiple data (SIMD), o per utilizzare unità di elaborazione grafica (GPU) o processori di segnale digitale (DSP).^[6]

L'approccio opposto al precedente consiste nel partire da un'applicazione o da un da uno specifico carico di lavoro e progettare l'hardware in modo da accelerarne l'esecuzione.^[5] Tra gli esempi più comuni rientrano i kernel di elaborazione di segnale, l'inferenza delle reti neurali, gli algoritmi crittografici, la codifica e decodifica video e le pipeline di elaborazione delle immagini.^[5]

Questo approccio è impiegato da tempo nei sistemi embedded e real-time, dove i vincoli di consumo energetico e le limitate risorse hardware rendono conveniente l'adozione di soluzioni personalizzate.^[2][3] Progettare l'hardware attorno a un carico di lavoro noto consente infatti di ottenere un rapporto prestazioni per watt superiore rispetto a quello offerto da un processore general-purpose. Negli ultimi anni, lo stesso principio è stato esteso al cloud computing su larga scala e ai data center, dove acceleratori per l'intelligenza artificiale, come le tensor processing unit (TPU), vengono impiegati per ridurre il consumo energetico e migliorare le prestazioni per watt.^[12]

Il co-design si distingue dai tre approcci descritti in precedenza perché nessuno dei due domini viene definito per primo. Hardware e software sono considerati parti di un unico processo di progettazione iterativo e collaborativo e vengono sviluppati congiuntamente in funzione di obiettivi comuni.^[2][3]

A partire da una specifica a livello di sistema, diverse possibili partizioni tra hardware e software vengono valutate sulla base di metriche quali prestazioni, consumo energetico, area e costo. Il processo è tipicamente iterativo: i risultati di ciascuna valutazione guidano le decisioni progettuali successive, consentendo di affinare progressivamente entrambe le componenti del sistema.^[2]

Il co-design hardware/software è ampiamente utilizzato nei sistemi che combinano processori general-purpose con hardware specifico per applicazione. I domini applicativi tipici includono:

• Sistemi embedded, dove il consumo energetico, l'area del chip e il costo di produzione sono i vincoli principali.^[3]
• Settore automobilistico e aerospaziale, dove cicli di controllo critici per la sicurezza devono soddisfare requisiti real-time.^[4]
• Telecomunicazioni ed elaborazione digitale del segnale, dove funzioni come filtraggio, modulazione e la correzione degli errori sono comunemente implementate in hardware dedicato.^[3]
• Visione artificiale ed elaborazione delle immagini, dove kernel di elaborazione dei pixel vengono spesso accelerati in hardware.^[5]
• Acceleratori di intelligenza artificiale, comprese le TPU, le neural processing unit (NPU) e i tensor core delle GPU, che vengono sviluppati insieme ai framework software e ai formati numerici che supportano.^[5][12]
• Data center e cloud computing, dove acceleratori basati su FPGA e ASIC vengono impiegati per accelerare carichi di lavoro legati a rete, archiviazione, basi di dati e apprendimento automatico^[5][14]
• Calcolo scientifico, dove acceleratori specifici per applicazione vengono utilizzati per eseguire in modo efficiente kernel computazionali, come calcoli a stencil, simulazioni di dinamica molecolare e operazioni di algebra lineare sparsa.^[5][15]

Un flusso di co-design hardware/software inizia tipicamente con una specifica a livello di sistema, seguita dalla partizione hardware/software, dall'esplorazione dello spazio di progetto e dalla stima delle prestazioni. Queste attività vengono generalmente svolte in modo iterativo, poiché i risultati di ciascuna fase influenzano spesso le decisioni prese nelle fasi successive.[^[2][7]

La partizione stabilisce, per ogni funzione o kernel computazionale, se debba essere implementato come software su un processore oppure come blocco hardware dedicato. I kernel costituiti da operazioni aritmetiche regolari e altamente parallelizzabili, come la convoluzione, la moltiplicazione di matrici o le fasi della trasformata veloce di Fourier (FFT), sono candidati ideali per un'implementazione hardware. Al contrario, il codice con una logica di controllo complessa, le operazioni eseguite raramente e le funzionalità che si prevede possano evolvere nel tempo vengono generalmente mantenuti nel software.^[2][7]

La partizione è generalmente formulata come un problema di ottimizzazione multi-obiettivo, nel quale si cerca un compromesso tra tempo di esecuzione, consumo energetico, area di silicio, larghezza di banda della memoria e sforzo di sviluppo. Tra gli approcci proposti figurano la programmazione lineare intera, il partizionamento di grafi, gli algoritmi evolutivi, il simulated annealing e, più recentemente, euristiche basate sull'apprendimento automatico.^[7]

Il numero di possibili partizioni e configurazioni hardware cresce molto rapidamente; per questo motivo si ricorre all'esplorazione dello spazio di progetto (Design Space Exploration, DSE) per limitare il numero di soluzioni da analizzare. Gli strumenti di DSE variano parametri quali il numero di acceleratori, la gerarchia di memoria e la frequenza di clock, valutando quindi le configurazioni ottenute rispetto agli obiettivi del sistema.^[5]

La valutazione delle diverse configurazioni può essere effettuata mediante modelli analitici, simulatori dell'insieme di istruzioni, modelli SystemC a livello transazionale e prototipi FPGA. Esiste un compromesso tra accuratezza e velocità: i modelli analitici consentono di analizzare rapidamente migliaia di configurazioni, mentre la simulazione a livello di ciclo e la prototipazione FPGA, più lente ma anche più accurate, vengono generalmente riservate a un numero limitato di soluzioni promettenti.^[16]

Metodi di valutazione utilizzati nell'esplorazione dello spazio di progetto

Metodo	Velocità relativa	Accuratezza relativa	Uso tipico
Modelli analitici	Molto veloce	Bassa	Selezione iniziale di molte configurazioni
Simulazione dell'insieme di istruzioni	Media	Media	Valutazione dei processori candidati
A livello di ciclo o SystemC	Lenta	Alta	Valutazione dettagliata delle configurazioni selezionate
Prototipazione FPGA	Lenta da configurare, veloce da eseguire	Molto alta	Validazione finale

Oltre alla scelta fondamentale tra hardware e software, il co-design comporta una serie di decisioni progettuali che coinvolgono entrambi i domini. Molte di esse sfruttano operazioni che risultano più efficienti se implementate in hardware piuttosto che in software, come gli scorrimenti di bit, il mascheramento, il parallelismo a livello di bit e l'aritmetica a latenza fissa.^[2]

Scelte comuni di co-design

Scelta	Effetto sull'hardware	Implicazioni per il software
Precisione ridotta	Riduzione del costo aritmetico e della larghezza di banda della memoria	Algoritmi numerici adattati alla precisione ridotta (come l'addestramento consapevole della quantizzazione per l'IA)
Suddivisione dei cicli in blocchi	Migliore località attraverso il riutilizzo della memoria on-chip	Struttura dei cicli e schemi di accesso ai dati adattati all'organizzazione dell'hardware
Numero di elementi di elaborazione	Maggiore grado di parallelismo hardware	Parallelismo esposto attraverso vettorizzazione, threading o trasformazioni dei cicli
Fisso rispetto a programmabile	Compromesso tra efficienza e flessibilità	Possibilità di adattarsi ad algoritmi e carichi di lavoro in evoluzione
Disposizione dei dati	Accesso efficiente alla memoria e interfacce degli acceleratori	Strutture dati organizzate in funzione della disposizione della memoria hardware

I processori general-purpose supportano un numero limitato di formati numerici standard, tipicamente numeri in virgola mobile a 32 e 64 bit e interi con larghezza compresa tra 8 e 64 bit. L'hardware personalizzato non è soggetto a questi vincoli e può utilizzare larghezze di bit arbitrarie, aritmetica in virgola fissa oppure formati in virgola mobile a precisione ridotta, come bfloat16, FP16, FP8 o la virgola mobile a blocchi. L'impiego di operandi rappresentati con un minor numero di bit riduce l'area occupata dai moltiplicatori in modo approssimativamente quadratico rispetto alla larghezza degli operandi e diminuisce proporzionalmente la larghezza di banda richiesta alla memoria, un aspetto particolarmente importante negli acceleratori per reti neurali.^[12][17]

La riduzione della precisione numerica modifica il risultato delle operazioni aritmetiche e può quindi richiedere l'adattamento degli algoritmi software. Nel caso degli acceleratori per reti neurali, ciò comporta tipicamente l'addestramento consapevole della quantizzazione (quantization-aware training), la calibrazione o altre tecniche volte a preservare l'accuratezza del modello alla precisione numerica scelta. La selezione della precisione numerica diventa quindi una decisione progettuale condivisa, che influenza sia l'implementazione hardware sia il modello software.^[12][17]

La memoria on-chip offre una larghezza di banda significativamente maggiore e un consumo energetico inferiore rispetto alla DRAM off-chip, ma dispone di una capacità limitata. Nella progettazione congiunta hardware/software, le dimensioni dei blocchi di elaborazione vengono scelte in modo che il working set dell'applicazione possa essere contenuto nelle cache on-chip. Di conseguenza, le dimensioni dei blocchi, la capacità della memoria on-chip e il numero di elementi di elaborazione paralleli vengono definiti congiuntamente. Ad esempio, in un acceleratore per la moltiplicazione di matrici, le dimensioni dell'array sistolico, la capacità dei buffer on-chip e la strategia di suddivisione in blocchi adottata dal software sono determinate dagli stessi parametri di progetto.^[5][13][17]

Il numero di elementi di elaborazione (PE), di corsie SIMD o di istanze di acceleratori viene scelto in funzione del grado di parallelismo disponibile nel carico di lavoro. In molti progetti, l'impiego di un numero di elementi pari a una potenza di due semplifica la decodifica degli indirizzi, gli alberi di riduzione e la progettazione dell'interconnessione, oltre ad allinearsi alle dimensioni dei blocchi utilizzate nella suddivisione dei dati. I kernel software sono generalmente strutturati in modo da esporre tale livello di parallelismo, ricorrendo a tecniche quali la vettorizzazione, il loop unrolling e le trasformazioni operate dal compilatore.^[7]

Il co-design determina anche il grado di flessibilità richiesto a un acceleratore. Un'implementazione completamente a funzione fissa minimizza l'area occupata e il consumo energetico, ma è in grado di eseguire una sola operazione. Al contrario, un acceleratore programmabile dotato di un insieme di istruzioni specifico per dominio offre una maggiore flessibilità, a fronte di una riduzione dell'efficienza, consentendo di adattare gli algoritmi senza dover riprogettare l'hardware. Le piattaforme riconfigurabili, come le FPGA, rappresentano una soluzione intermedia, poiché permettono di modificare l'implementazione hardware anche dopo la fabbricazione, in parallelo all'evoluzione del software.^[5]

L'interfaccia tra il processore e un acceleratore è un fattore chiave nel determinare le prestazioni complessive del sistema ed è generalmente progettata insieme all'applicazione o al carico di lavoro di destinazione. I meccanismi di comunicazione più comuni includono registri mappati in memoria, memoria condivisa, motori di accesso diretto alla memoria (DMA), interrupt e FIFO in streaming. Quando tra processore e acceleratore vengono trasferite grandi quantità di dati, il costo del trasferimento e il sovraccarico dovuto alla coerenza della cache possono ridurre, o addirittura annullare, i benefici prestazionali dell'accelerazione.^[5][10]

Un esempio di decisione di co-design hardware/software è la scelta di utilizzare parametri espressi come potenze di due. Nell’hardware digitale, la moltiplicazione o la divisione per una costante pari a una potenza di due può essere implementata mediante uno scorrimento di bit costante, mentre il resto di una divisione per una potenza di due può essere ottenuto tramite una maschera bit a bit (operazione AND), entrambe operazioni che richiedono una quantità significativamente inferiore di logica hardware.^[13][18] Analogamente, l’indirizzamento di buffer circolari o di memorie di dimensione pari a una potenza di due può essere semplificato utilizzando direttamente i bit meno significativi dell’indirizzo, anziché mediante un’operazione di modulo.^[13][18]

Quando un’implementazione hardware sfrutta tali proprietà, vengono introdotti vincoli corrispondenti anche sul software. Le dimensioni degli array, dei buffer e dei blocchi, così come i limiti dei cicli, possono essere definiti come potenze di due, con gli elementi non utilizzati gestiti mediante riempimento (padding) o mascheramento. In questo modo, i parametri numerici diventano decisioni progettuali condivise, che influenzano sia l’implementazione hardware sia il software che vi viene eseguito.^[2]

Lo spazio di progetto combinato hardware/software è tipicamente molto ampio, il che rende la suddivisione automatica e l’esplorazione dello spazio di progetto strumenti fondamentali, anche se le decisioni progettuali pratiche richiedono comunque la guida dell’ingegnere e una conoscenza approfondita del dominio applicativo.^[7][16] Anche la verifica risulta più complessa, poiché hardware, software e la loro interazione devono essere analizzati congiuntamente. Gli errori di implementazione possono riguardare la concorrenza o incoerenze di interfaccia che non emergerebbero considerando separatamente i due domini.^[16]

I benefici di prestazioni possono essere ridotti o annullati se il trasferimento dei dati tra processore e acceleratore non viene attentamente considerato in fase di progettazione, poiché il sovraccarico di comunicazione può dominare il tempo di esecuzione in alcuni carichi di lavoro.^[12]

Nella progettazione ASIC, il co-design può comportare cicli di sviluppo lunghi a causa dei costi e dei tempi necessari per la fabbricazione dell’hardware, sebbene le piattaforme riconfigurabili come le FPGA attenuino questa limitazione consentendo modifiche dopo la produzione.^[11]

Infine, i sistemi hardware/software strettamente accoppiati possono risultare più difficili da mantenere ed evolvere, poiché le modifiche al software possono richiedere corrispondenti modifiche nelle ipotesi hardware, come larghezze dei dati, layout di memoria o strutture di parallelizzazione.^[1]

Poiché lo spazio di progetto hardware/software è tipicamente molto ampio, il co-design hardware/software si basa in larga misura sugli strumenti di automazione della progettazione elettronica. I linguaggi di modellazione a livello di sistema e i linguaggi di descrizione dell’hardware sono utilizzati per rappresentare hardware e software all’interno di un framework unificato, mentre la sintesi ad alto livello consente di generare hardware a partire da linguaggi di programmazione ad alto livello come C e C++.^[10] Gli strumenti di simulazione, i modelli basati su SystemC e i prototipi FPGA sono comunemente impiegati per valutare le scelte progettuali e guidare l’esplorazione dello spazio di progetto.^[7]

La ricerca attuale nel co-design hardware/software si concentra principalmente sul miglioramento dell’automazione del processo di progettazione e sull’estensione delle metodologie di co-design alle piattaforme di calcolo emergenti. Le principali linee di ricerca includono la suddivisione e l’esplorazione dello spazio di progetto assistite da modelli di intelligenza artificiale,^[19] la generazione di acceleratori assistita dal compilatore, la riconfigurazione a runtime nelle FPGA,^[20] e le strategie di ottimizzazione energetica per sistemi edge e data center.^[5][7]

Più recentemente, le tecniche di co-design sono state applicate anche agli acceleratori per l’intelligenza artificiale e ad altre architetture di calcolo specifiche per dominio, inclusi sistemi destinati ai large language model e ai carichi di lavoro di intelligenza artificiale generativa. In questi contesti, l’attenzione è sempre più rivolta al miglioramento dell’efficienza energetica e dell’utilizzo delle risorse, sia nelle applicazioni edge sia nei data center.^[5][21]

• Analisi delle prestazioni
• Efficienza energetica
• Field programmable gate array
• Hardware
• Sistema embedded
• Software

• SystemC, su accellera.org. – Pagina introduttiva del linguaggio SystemC
• Vitis HLS, su amd.com. – Pagina introduttiva di AMD Vitis HLS
• Intel openAPI, su intel.com. – Pagina introduttiva di Intel openAPI