L'architettura di coprocessore: un'architettura di sistema embedded per la prototipazione rapida

Nota del redattore - Anche se ben nota per le sue prestazioni di elaborazione digitale e il throughput, l'architettura di coprocessore fornisce al progettista di sistemi embedded la possibilità di implementare strategie di gestione progettuale che abbattono i costi di sviluppo e il time-to-market. Questo articolo, incentrato specificamente sulla combinazione di un microcontroller discreto (MCU) e un gate array programmabili sul campo (FPGA) discreto, mostra come questa architettura si presta a un processo di progettazione efficiente e iterativo. Sfruttando fonti ricercate, risultati empirici e casi di studio, esploreremo i vantaggi di questa architettura alla luce di alcune applicazioni di esempio. Alla conclusione di questo articolo, il progettista di sistemi embedded avrà una migliore comprensione di quando e come implementare questa versatile architettura hardware.

Introduzione

Il progettista di sistemi embedded si trova in una congiuntura, da un lato vincoli di progettazione, aspettative di prestazioni e dall'altro preoccupazioni sui tempi e sui costi. Infatti, anche le contraddizioni nelle moderne espressioni sulla gestione dei progetti sottolineano ulteriormente la natura precaria di questo ruolo: "sbagliare subito", "essere agili", "a prova di futuro" e "essere disruptivo". Le acrobazie che si fanno anche solo per cercare di soddisfare queste aspettative possono essere rocambolesche, eppure sono state dette e continuano ad essere rafforzate in tutto il mercato. C'è bisogno di un approccio progettuale che permetta di implementare un processo iterativo evolutivo, e proprio come per la maggior parte dei sistemi embedded, inizia con l'architettura hardware.

L'architettura di coprocessore, un'architettura hardware nota per combinare i punti di forza di entrambe le tecnologie MCU (unità microcontroller) e FPGA (gate array programmabili sul campo), può offrire al progettista embedded un processo in grado di soddisfare anche i requisiti più esigenti, pur tuttavia con la flessibilità necessaria per affrontare sfide note e ignote. Fornendo un hardware capace di adattarsi iterativamente, il progettista può dimostrare i progressi, centrare le fasi chiave del progetto e trarre pieno vantaggio dal processo di prototipazione rapida.

All'interno di questo processo ci sono i milestone del progetto, ognuno con il proprio valore unico da aggiungere allo sforzo di sviluppo. In questo articolo, vi faremo riferimento con i seguenti termini: Elaborazione di segnali digitali con il microcontroller, Gestione del sistema con il microcontroller e Distribuzione del prodotto.

Per la conclusione di questo articolo, sarà dimostrato che un'architettura hardware flessibile può essere più adatta alla progettazione dei moderni sistemi embedded rispetto a un approccio più rigido. Inoltre, questo approccio può portare a miglioramenti sia del costo del progetto che del time-to-market. Argomenti, esempi forniti e casi di studio saranno usati per difendere questa posizione. Osservando il valore di ogni milestone all'interno della flessibilità di progettazione che questa architettura fornisce, diventa chiaro che un'architettura hardware adattiva è un movente per la progettazione dei sistemi embedded.

Esplorare i punti di forza dell'architettura di coprocessore: flessibilità di progettazione ed elaborazione ad alte prestazioni

Un uso comune dei progetti FPGA è l'interfacciamento diretto con un convertitore analogico/digitale (ADC) ad alta velocità. Il segnale viene digitalizzato, letto nell'FPGA e poi elaborato con alcuni algoritmi del processore di segnali digitali (DSP). Infine, l'FPGA prende decisioni sulla base dei risultati.

Una tale applicazione servirà da esempio in questo articolo. Inoltre, la Figura 1 illustra un'architettura generica di coprocessore, dove l'MCU e l'FPGA sono collegati attraverso l'interfaccia di memoria esterna dell'MCU. L'FPGA è considerato un pezzo esterno di memoria statica ad accesso casuale (SRAM). I segnali tornano all'MCU dall'FPGA e servono come linee di interrupt hardware e indicatori di stato. Questo permette all'FPGA di indicare stati critici all'MCU, come comunicare che una conversione ADC è pronta o che si è verificato un errore o un altro evento degno di nota.

Figura 1: Schema generico di un coprocessore (MCU + FPGA). (Immagine per gentile concessione di CEPD)

I punti di forza dell'approccio coprocessore saltano all'occhio con i risultati di ciascuno dei milestone sopra menzionati. Il valore viene valutato non solo elencando i risultati di un'attività o di una fase, ma anche valutando ciò che questi risultati permettono di fare. Le risposte alle seguenti domande aiutano a valutare il valore complessivo dei risultati di un milestone:

• Gli altri membri del team possono ora progredire più rapidamente, ora che le dipendenze e i colli di bottiglia del progetto sono stati rimossi?
• In che modo i risultati del milestone permettono ulteriori percorsi di esecuzione parallela?

Il milestone Elaborazione di segnali digitali con il microcontroller

Figura 2: Architettura - elaborazione di segnali digitali con il microcontroller. (Immagine per gentile concessione di CEPD)

La prima fase di sviluppo con questa architettura hardware pone al centro l'MCU. A parità di condizioni, lo sviluppo di MCU e di software eseguibile richiede meno risorse e minor tempo rispetto allo sviluppo di FPGA e del linguaggio di descrizione dell'hardware (HDL). Quindi, iniziando lo sviluppo del prodotto con l'MCU come processore principale, gli algoritmi possono essere implementati, testati e convalidati più rapidamente. Ciò permette di scoprire i bug algoritmici e logici all'inizio del processo di progettazione, nonché di testare e convalidare grandi porzioni della catena di segnali.

In questo milestone l'FPGA ha il ruolo di servire come interfaccia di raccolta dati ad alta velocità. Ha il compito di convogliare in modo affidabile i dati dall'ADC ad alta velocità, avvisare l'MCU che i dati sono disponibili e presentare questi dati sull'interfaccia di memoria esterna dell'MCU. Sebbene questo ruolo non includa l'implementazione di processi DSP basati su HDL o altri algoritmi, è comunque molto critico.

Lo sviluppo di FPGA eseguito in questa fase getta le basi per il successo finale del prodotto sia nell'ottica degli sforzi di sviluppo del prodotto sia del rilascio sul mercato. Concentrandosi solo sull'interfaccia di basso livello, si può dedicare un tempo adeguato al test di queste operazioni essenziali. Solo una volta che l'FPGA svolge in modo affidabile e sicuro questo ruolo di interfacciamento, questo milestone può dirsi concluso.

I vantaggi dei risultati chiave di questo milestone iniziale includono:

1. L'intero percorso del segnale - tutte le amplificazioni, attenuazioni e conversioni - sarà stato testato e convalidato.
2. Il tempo e lo sforzo di sviluppo del progetto saranno stati ridotti implementando inizialmente gli algoritmi in un software (C/C++); questo è di notevole valore per la direzione e altri stakeholder, che devono capire la fattibilità di un tale progetto prima di approvare le future fasi di progettazione.
3. Le lezioni apprese dall'implementazione degli algoritmi in C/C++ saranno direttamente trasferibili alle implementazioni HDL attraverso l'uso di strumenti software-HDL, come Xilinx HLS.

Il milestone Gestione del sistema con il microcontroller

Figura 3: Architettura - gestione del sistema con il microcontroller. (Immagine per gentile concessione di CEPD)

La seconda fase di sviluppo con questo approccio di coprocessore, è definita dallo spostamento dei processi DSP e delle implementazioni degli algoritmi dall'MCU all'FPGA. L'FPGA è sempre responsabile dell'interfaccia ADC ad alta velocità tuttavia, assumendo questi altri ruoli, la velocità e il parallelismo offerti dall'FPGA sono pienamente utilizzati. Inoltre, a differenza dell'MCU, possono essere implementate ed eseguite simultaneamente più istanze dei processi DSP e dei canali dell'algoritmo.

Il progettista, fa forte quanto appreso dall'implementazione dell'MCU, trasferisce la sua conoscenza al nel prossimo milestone. Gli strumenti, come il già citato Vivado HLS di Xilinx, forniscono una traduzione funzionale dal codice C/C++ eseguibile all'HDL sintetizzabile. Ora, i vincoli di tempo, i parametri di processo e altre preferenze dell'utente devono ancora essere definiti e implementati, tuttavia la funzionalità di base è mantenuta e tradotta nel tessuto FPGA.

Per questo milestone, l'MCU ricopre il ruolo di un gestore del sistema. I registri di stato e di controllo all'interno dell'FPGA sono monitorati, aggiornati e riportati dall'MCU. Inoltre, l'MCU gestisce l'interfaccia utente (UI). Questa UI potrebbe assumere la forma di un server web cui si accede tramite una connessione Ethernet o Wi-Fi oppure potrebbe essere un'interfaccia industriale touchscreen che dà accesso agli utenti nel punto di utilizzo. Il risultato chiave del nuovo e più raffinato ruolo dell'MCU è questo: non dovendo svolgere attività di elaborazione ad alta intensità di calcolo, sia l'MCU che l'FPGA ora sono sfruttati in attività alle quali si prestano bene.

I risultati chiave di questo milestone comportano questi vantaggi:

1. L'FPGA fornisce un'esecuzione veloce e parallela di processi DSP e implementazioni di algoritmi.L'MCU fornisce un'interfaccia utente reattiva e semplificata e gestisce i processi del prodotto.
2. Essendo stato prima sviluppato e convalidato all'interno dell'MCU, i rischi algoritmici sono stati mitigati e queste mitigazioni sono tradotte in HDL sintetizzabile. Gli strumenti, come Vivado HLS, facilitano questa traduzione. Inoltre, i rischi specifici dell'FPGA possono essere mitigati attraverso strumenti di simulazione integrati, come la suite di progettazione Vivado.
3. Gli stakeholder non sono esposti a rischi significativi quando trasferiscono i processi sull'FPGA. Anzi, possono vedere e godere dei vantaggi dati dalla velocità e dal parallelismo dell'FPGA. Si osservano miglioramenti misurabili delle prestazioni e ci si può ora concentrare sulla preparazione di questo progetto per la produzione.

Il milestone della distribuzione del prodotto

Con l'elaborazione ad alta intensità di calcolo affrontata all'interno dell'FPGA - e con l'MCU che gestisce i suoi ruoli di gestione del sistema e di interfaccia utente - il prodotto è pronto per la distribuzione. Ora, questo documento non suggerisce di bypassare le versioni Alpha e Beta; tuttavia, l'enfasi in questo milestone sono le capacità che l'architettura di coprocessore fornisce all'implementazione del prodotto.

Sia l'MCU che l'FPGA sono dispositivi aggiornabili sul campo. Sono stati fatti diversi progressi per rendere gli aggiornamenti FPGA accessibili al pari di quelli software. Inoltre, poiché l'FPGA è all'interno dello spazio di memoria indirizzabile dell'MCU, quest'ultimo può servire come access point per l'intero sistema, ossia ricevere gli aggiornamenti per se stesso e per l'FPGA. Gli aggiornamenti possono essere programmati in modo condizionale, distribuiti e personalizzati per l'utente finale. Infine, i registri degli utenti e dei casi d'uso possono essere mantenuti e associati a specifiche implementazioni del build. Da questi insiemi di dati, le prestazioni possono continuare ad essere perfezionate e migliorate anche dopo che il prodotto è attivo sul campo.

I punti di forza di questa aggiornabilità totale del sistema sono più apparenti nelle applicazioni spaziali. Una volta che un prodotto viene lanciato, la manutenzione e gli aggiornamenti devono essere eseguiti a distanza. Questo potrebbe essere semplice, come cambiare le condizioni logiche, ma anche complicato, come aggiornare uno schema di modulazione delle comunicazioni. La programmabilità offerta dalle tecnologie FPGA e dall'architettura di coprocessore possono accogliere la totalità di questa gamma di capacità, il tutto offrendo scelte di componenti resistenti alle radiazioni.

L'ultimo risultato chiave di questo milestone è la riduzione progressiva dei costi. Anche la riduzioni dei costi, le modifiche alla distinta base (BOM) e altre ottimizzazioni possono avvenire in questo milestone. Durante l'implementazione sul campo, si può scoprire che il prodotto può funzionare altrettanto bene con un MCU meno costoso o un FPGA meno capace. Grazie al coprocessore, i progettisti di architetture non sono forzati a usare componenti le cui capacità superano le necessità della loro applicazione. Inoltre, se un componente non è più disponibile, l'architettura permette di integrare nuovi componenti nel progetto. Questo non avviene in un'architettura a chip singolo, System-on-Chip (SoC) o DSP o MCU ad alte prestazioni che cerca di gestire tutta l'elaborazione del prodotto. L'architettura di coprocessore è un buon mix di capacità e flessibilità che dà al progettista più scelte e libertà sia nelle fasi di sviluppo, sia al momento del rilascio sul mercato.

Ricerca di supporto e case study correlati

Esempio di comunicazione satellitare

In breve, il valore di un coprocessore è di alleviare l'unità di elaborazione primaria in modo che le attività siano eseguite a livello di hardware, dove possono essere sfruttate le accelerazioni e l'ottimizzazione. Il vantaggio di una tale scelta progettuale è un aumento netto della velocità e delle capacità di calcolo e, come sostiene questo articolo, una riduzione dei costi e dei tempi di sviluppo. Forse uno degli ambiti più interessanti di questi vantaggi riguarda i sistemi di comunicazione spaziale.

Nella pubblicazione FPGA based hardware as coprocessor, G. Prasad e N. Vasantha spiegano come l'elaborazione dei dati all'interno di un FPGA fonde le esigenze computazionali dei sistemi di comunicazione satellitare senza gli alti costi NRE (Non-Recurring Engineering) dei circuiti integrati specifici per applicazione (ASIC) o le limitazioni specifiche delle applicazioni di un processore ad architettura rigida. Proprio come è stato descritto nel milestone Elaborazione di segnali digitali con il microcontroller, il loro progetto inizia con il processore applicativo che esegue la maggior parte degli algoritmi ad alta intensità di calcolo. Da questo punto di partenza, identificano le sezioni chiave del software che consumano la maggior parte dei cicli dell'unità di elaborazione centrale (CPU) e migrano queste sezioni all'implementazione HDL. La rappresentazione grafica è molto simile a ciò che è stato presentato finora; tuttavia, hanno scelto di rappresentare il programma applicativo come un proprio blocco indipendente, poiché può essere realizzato sia nell'host (processore) che nell'hardware basato su FPGA.

Figura 4: Programma applicativo, processore host e hardware basato su FPGA - usato nell'esempio delle comunicazioni satellitari

Utilizzando un'interfaccia PCI (interconnessione di componenti periferici) e l'accesso diretto alla memoria (DMA) del processore host, le prestazioni delle periferiche aumentano notevolmente. Questo si osserva soprattutto all'interno dei miglioramenti per il processo di de-randomizzazione. L'esecuzione di questo processo nel software del processore host ha presentato chiaramente un collo di bottiglia nella risposta in tempo reale del sistema. Tuttavia, quando è stato spostato sull'FPGA, sono stati osservati i seguenti vantaggi:

• Il processo di de-randomizzazione si è eseguito in tempo reale senza causare colli di bottiglia
• Il sovraccarico computazionale del processore host è stato significativamente ridotto e ora può svolgere meglio il ruolo desiderato.
• Le prestazioni totali dell'intero sistema sono aumentate.

Tutto questo è stato ottenuto senza i costi associati a un ASIC, e godendo della flessibilità della logica programmabile [5]. Le comunicazioni satellitari presentano sfide notevoli e questo approccio può soddisfare in modo verificabile questi requisiti, oltre a continuare a fornire flessibilità di progettazione.

Esempio di infotainment automotive

I sistemi di intrattenimento per le automobili sono caratteristiche distintive per i consumatori più esigenti. A differenza della maggior parte dell'elettronica automotive, questi dispositivi sono altamente visibili e ci si aspetta che forniscano tempi di risposta e prestazioni eccezionali. Tuttavia, i progettisti sono spesso tra due fuochi, da un lato le esigenze attuali del progetto e dall'altro la flessibilità per accomodare funzionalità future. Per questo esempio, saranno utilizzate le esigenze di implementazione dell'elaborazione dei segnali e delle comunicazioni wireless per evidenziare i punti di forza dell'architettura hardware di coprocessore.

Una delle architetture predominanti del sistema di intrattenimento automotive è stata pubblicata da Delphi Delco Electronics Systems Corporation. Questa architettura impiegava un MCU SH-4 con un ASIC abbinato, la periferica Amanda HD64404 di Hitachi. Questa architettura soddisfaceva oltre il 75% delle funzionalità di intrattenimento di base del mercato automotive; tuttavia, mancava la capacità di affrontare le applicazioni di elaborazione video e le comunicazioni wireless. Includendo un FPGA in questa architettura esistente, è possibile aggiungere altra flessibilità e capacità a questo approccio di progettazione già esistente.

Figura 5: Esempio di un'architettura di coprocessore FPGA per infotainment 1

L'architettura della Figura 5 è adatta sia all'elaborazione video, sia alla gestione delle comunicazioni wireless. Trasferendo le funzionalità DSP all'FPGA, il processore Amanda può assolvere un ruolo di gestione del sistema ed è libero di implementare uno stack di comunicazioni wireless. Poiché sia il processore Amanda sia l'FPGA hanno accesso alla memoria esterna, i dati possono essere scambiati rapidamente tra i processori e i componenti del sistema.

Figura 6: Esempio di un'architettura di coprocessore FPGA per infotainment 2

Il secondo esempio di infotainment nella Figura 6 evidenzia la capacità dell'FPGA di affrontare sia i dati analogici ad alta velocità in entrata che la gestione della compressione e della codifica necessarie per le applicazioni video. In effetti, tutte queste funzionalità possono essere trasferite all'FPGA e attraverso l'uso dell'elaborazione parallela, tutte queste possono essere affrontate in tempo reale.

Includendo un FPGA in un'architettura hardware esistente, le prestazioni comprovate dell'hardware esistente possono essere accoppiate con una flessibilità a prova di futuro. Anche all'interno dei sistemi esistenti, l'architettura di coprocessore fornisce ai progettisti opzioni altrimenti non disponibili [6].

Vantaggi della prototipazione rapida

Fondamentalmente, il processo di prototipazione rapida si sforza di coprire una quantità sostanziale di area di sviluppo del prodotto eseguendo compiti in parallelo, identificando "bug" e problemi di progettazione rapidamente e convalidando dati e percorsi di segnale, specialmente quelli all'interno del percorso critico di un progetto. Tuttavia, perché questo processo produca veramente risultati snelli ed efficienti, deve esserci sufficiente competenza nelle aree di progetto richieste.

Tradizionalmente, questo implica un ingegnere hardware, un ingegnere software embedded o DSP e un ingegnere HDL. Ora, esistono molti professionisti interdisciplinari capaci di soddisfare più ruoli; tuttavia, il costo di progetto è sostanziale per coordinare questi sforzi.

Nel loro paper, An FPGA based rapid prototyping platform for wavelet coprocessors, gli autori promuovono l'idea che l'utilizzo di un'architettura di coprocessore permette a un singolo ingegnere DSP di soddisfare tutti questi ruoli, in modo efficiente ed efficace. Per questo studio, il team ha iniziato a progettare e simulare la funzionalità DSP desiderata con lo strumento Simulink di MATLAB. Questo assolveva due funzioni primarie, 1) verificava le prestazioni desiderate attraverso la simulazione e 2) fungeva da baseline per il confronto e il riferimento delle scelte di progettazione future.

Dopo la simulazione, le funzionalità critiche sono state identificate e divise in diversi core - questi sono componenti soft-core e processori che possono essere sintetizzati in un FPGA. Il passo più importante durante questo lavoro è stato quello di definire l'interfaccia tra questi core e componenti e di confrontare le prestazioni di scambio dati con quelle desiderate e simulate. Questo processo di progettazione è strettamente allineato con il flusso di progettazione di Xilinx per i sistemi embedded ed è riassunto nella figura 7 qui sotto.

Figura 7: Flusso di progettazione dell'implementazione

Dividendo il sistema in core sintetizzabili, l'ingegnere DSP può concentrarsi sugli aspetti più critici della catena di elaborazione dei segnali. Non deve essere un esperto hardware o HDL per modificare, instradare o implementare diversi processori soft-core o componenti all'interno dell'FPGA. Finché il progettista è consapevole dell'interfaccia e dei formati dei dati, ha il pieno controllo sui percorsi del segnale e può perfezionare le prestazioni del sistema.

Risultati empirici - il case study della trasformata discreta del coseno

I risultati empirici non solo hanno confermato la flessibilità offerta dall'architettura di coprocessore al progettista di sistemi embedded, ma hanno anche mostrato le opzioni di miglioramento delle prestazioni disponibili con i moderni strumenti FPGA. I miglioramenti, come quelli menzionati di seguito, potrebbero non essere disponibili o avere un impatto minore per altre architetture hardware. La trasformazione discreta del coseno (DCT) è stata selezionata come un algoritmo ad alta densità di calcolo e la sua progressione da un'implementazione basata su C a una basata su HDL è al centro di questi risultati. DCT è stato scelto perché è un algoritmo usato nell'elaborazione dei segnali digitali per il riconoscimento per paragone di immagini e il filtraggio [8]. I risultati empirici si basano su un esercizio di laboratorio, completato dall'autore e dai suoi collaboratori, per ottenere la certificazione Xilinx Alliance Partner per il 2020-2021.

Sono stati utilizzati i seguenti strumenti e dispositivi:

• Vivado HLS v2019
• Dispositivo xczu7ev-ffvc1156-2-e per la valutazione e la simulazione

A partire dall'implementazione basata su C, l'algoritmo DCT accetta due matrici di numeri a 16 bit; la matrice "a" è quella di ingresso al DCT e la matrice "b" è quella di uscita dal DCT. La larghezza dei dati (DW) è quindi definita come 16 e il numero di elementi negli array (N) è 1024/DW, ossia 64. Infine, la dimensione della matrice DCT (DCT_SIZE) è impostata su 8, il che significa che viene usata una matrice 8x8.

Seguendo la premessa di questo articolo, l'implementazione dell'algoritmo basata su C permette al progettista di sviluppare e convalidare rapidamente la funzionalità dell'algoritmo. Anche se è una considerazione importante, questa convalida attribuisce alla funzionalità un peso maggiore rispetto al tempo di esecuzione. Questa ponderazione è permessa, poiché l'implementazione finale di questo algoritmo sarà in un FPGA, dove l'accelerazione hardware, lo svolgimento del ciclo e altre tecniche sono facilmente disponibili.

Figura 8: Flusso di progettazione con Vivado HLS di Xilinx

Una volta creato che il codice DCT come progetto con lo strumento Vivado HLS, il passo successivo è quello di iniziare a sintetizzare il progetto per l'implementazione FPGA. È qui che diventano più evidenti alcuni dei vantaggi più impattanti dello spostamento dell'esecuzione di un algoritmo da un MCU a un FPGA - come riferimento questo passo è equivalente al milestone Gestione del sistema con il microcontroller discusso in precedenza.

I moderni strumenti FPGA permettono una serie di ottimizzazioni e miglioramenti che aumentano notevolmente le prestazioni di algoritmi complessi. Prima di analizzare i risultati, ci sono alcuni termini importanti da tenere a mente:

• Latenza - Il numero di cicli di clock necessari per eseguire tutte le iterazioni del ciclo [10]
• Intervallo - Il numero di cicli di clock prima che la successiva iterazione di un ciclo inizi ad elaborare i dati [11]
• BRAM - Memoria ad accesso casuale a blocchi
• DSP48E - Slice di elaborazione di segnali digitali per l'architettura UltraScale
• FF - Flip-flop
• LUT - Tabella di ricerca
• URAM - Memoria ad accesso casuale unificata (può essere composta da un singolo transistor)

Tabella 1: Risultati dell'ottimizzazione dell'esecuzione dell'algoritmo FPGA (latenza e intervallo)

Tabella 2: Risultati dell'ottimizzazione dell'esecuzione dell'algoritmo FPGA (utilizzo delle risorse)

Standard

L'impostazione di ottimizzazione predefinita deriva dal risultato inalterato della traduzione dell'algoritmo basato su C in HDL sintetizzabile. Non è abilitata alcuna ottimizzazione e questo può essere usato come riferimento di prestazioni per capire meglio le altre ottimizzazioni.

Ciclo interno pipeline

La direttiva PIPELINE istruisce Vivado HLS a svolgere i cicli interni in modo che i nuovi dati possano iniziare ad essere elaborati mentre i dati esistenti sono ancora nella pipeline. Così, i nuovi dati non devono aspettare che i dati esistenti siano completi prima di iniziare l'elaborazione.

Ciclo esterno pipeline

Applicando la direttiva PIPELINE al ciclo esterno, le operazioni del ciclo esterno sono ora nella pipeline. Tuttavia, le operazioni dei cicli interni ora avvengono simultaneamente. Sia la latenza che l'intervallo sono dimezzati applicando questo parametro direttamente al ciclo esterno.

Partizione array

Questa direttiva mappa il contenuto dei cicli agli array e quindi appiattisce tutti gli accessi alla memoria ai singoli elementi all'interno di questi array. In questo modo, si consuma più RAM, ma il tempo di esecuzione di questo algoritmo viene dimezzato.

Flusso di dati

Questa direttiva permette al progettista di specificare il numero target di cicli di clock tra ciascuna delle letture in ingresso. Questa direttiva è supportata solo per le funzioni di primo livello. Solo i cicli e le funzioni esposte a questo livello trarranno vantaggio da questa direttiva.

In linea

La direttiva INLINE appiattisce tutti i cicli, interni ed esterni. Entrambi i processi di riga e di colonna possono ora essere eseguiti simultaneamente. Il numero di cicli di clock richiesti è mantenuto al minimo, anche se questo consuma più risorse FPGA.

Conclusione

L'architettura hardware di coprocessore fornisce al progettista embedded una piattaforma ad alte prestazioni che assicura flessibilità di progettazione durante lo sviluppo e il rilascio del prodotto. Convalidando prima gli algoritmi in C o C++, i processi, i percorsi dei dati e dei segnali e le funzionalità critiche possono essere verificati in un tempo relativamente breve. Poi, traducendo gli algoritmi che richiedono un processore nel coprocessore FPGA, il progettista può trarre vantaggio dall'accelerazione hardware e da un progetto più modulare.

Se i componenti diventano obsoleti o sono necessarie ottimizzazioni, la stessa architettura può accomodare questi cambiamenti. Nuove MCU e nuovi FPGA possono essere inseriti nel progetto, mentre le interfacce possono rimanere relativamente intatte. Inoltre, poiché sia l'MCU che l'FPGA sono aggiornabili sul campo, le modifiche e le ottimizzazioni specifiche dell'utente possono essere applicate sul campo e in remoto.

In conclusione, questa architettura unisce la velocità di sviluppo e la disponibilità di un MCU alle prestazioni e all'espandibilità di un FPGA. Con ottimizzazioni e miglioramenti delle prestazioni disponibili in ogni fase di sviluppo, l'architettura di coprocessore può soddisfare anche i requisiti più impegnativi - sia per i progetti attuali che per quelli futuri.