FPGA: Numeri a virgola fissa (seconda parte)

Dopo aver introdotto i numeri fixed point vediamo un semplice blocco in VHDL che calcola la circonferenza di un cerchio dato il raggio.

Possiamo vedere come sia stata definita una costante two_pi che intuitivamente conterrà il valore 2 * pi greco.

La costante è valorizzata tramite la funzione to_ufixed che provvederà a convertire un numero REAL (ma funziona anche con INTEGER, SIGNED e UNSIGNED)  nel tipo per l'appunto UFIXED senza dover convertire "a mano" il numero nella stringa di bit "00110010", approssimazione di 6.28 data la rappresentazione del numero con soli 3 bit per la parte decimale.

Il valore effettivo ottenuto sarà però 6.25, c'è quindi da porre particolare attenzione alla precisione con la quale si eseguono questo tipo di calcoli, il codice VHDL può infatti facilmente trarre in inganno.

Il raggio è costituito da un numero fixed point ad 8 bit mentre il risultato, per evitare overflow, è un numero di 16 bit, dato che è il prodotto di una moltiplicazione.

Per evitare errori in fase di compilazione bisogna tassativamente seguire le regole di dimensionamento, concepite per evitare problemi involontari di overflow, sotto riportate:

Nel nostro caso ci serviamo della riga A * B della tabella. A'left assume il valore INTEG_BIT-1, dato dal bound sinistro scelto nel tipo ufixed del segnale radius, mentre analogamente B'left vale INTEG_BIT-1, dato dalla costante two_pi.

A'right ed B'right avranno entrambi il valore -DECIM_BIT.

Il risultato dovrà avere, seguendo la tabella, un range pari a 2*(INTEG_BIT-1)+1 downto -2*DECIM_BIT, ovvero 9 downto -6 quindi un numero di 16 bit come già detto.

Il VHDL 2008 coi fixed point ci offre una funzione di ridimensionamento con saturazione (per problematiche di overflow) ed arrotondamento (per problematiche di underflow) chiamata resize per eventualmente adattare il risultato ad un numero con diversa risoluzione, vediamone un esempio:

Dove abbiamo come argomenti di resize il numero da ridimensionare, il bound sinistro ed il bound destro del risultato. In tal modo l'uscita circumference avrà la stessa dimensione di 8 bit dell'ingresso.

Sono disponibili diversi overload della funziona resize e rimando alla Fixed point package user’s guide per una descrizione esaustiva di tutte le funzioni.

Nella funzione resize di default sono abilitati l'arrotondamento e la saturazione, seppur è possibile scegliere di troncare e avvolgere (wrap) il valore per ottenere circuiti di velocità maggiore ed area minore.

Sotto è riportata la vista RTL del circuito generato con arrotondamento e saturazione abilitati

L'implementazione su Cyclone V è di 11 ALM ed 1 blocco DSP. Sotto è riportata una simulazione del blocco sopra descritto:

E' possibile notare come l'uscita saturi a 31.875 (tutti i bit pari ad 1) in caso di valori d'ingresso eccessivi per la risoluzione utilizzata.

Disabilitando arrotondamento e saturazione, il circuito ottenuto sarà come è facile aspettarsi costituito dal solo moltiplicatore, implementato con un singolo DSP. Purtroppo spesso il risultato così ottenuto è poco utilizzabile.



Per modificare lo stile di arrotondamento e di overflow in tutte le operazioni è possibile modificare le costanti fixed_round_style e fixed_overflow_style nel file fixed_pkg_c.vhdl

Per gestire l'underflow, che può verificarsi quando la parte decimale non ha abbastanza risoluzione per rappresentare il risultato, si può utilizzare una modalità fixed_round in cui la parte decimale viene arrotondata al più vicino valore rappresentabile oppure una modalità fixed_truncate dove sono semplicemente persi i bit meno significativi.

L'underflow può verificarsi nella divisione, dove l'errore può accumularsi a causa della natura iterativa degli algoritmi. Per ridurre l'errore vengono inseriti automaticamente dei bit di guardia (guard bit) che aumentano temporaneamente la risoluzione della parte decimale nei calcoli intermedi. Di default il VHDL 2008 utilizza 3 bit di guardia per operazioni come la divisione.

Per gestire l'overflow è possibile utilizzar la modalità fixed_saturate oppure la modalità fixed_wrap che è spesso il "normale" comportamento dei calcolatori e non comporta l'utilizzo di hardware aggiuntivo, incrementando il numero più grande rappresentabile si otterrà il numero più piccolo.

Per singole operazioni è possibile utilizzare gli overload delle funzioni come per esempio

Non mi rimane che augurarvi buona aritmetica.. coi fixed point!

NB: Per rendere compatibile il codice mostrato con ModelSim e compilabile da Quartus 15 è stato modificato il nome della libreria ieee_proposed in ieee, modificando il file fixed_pkg_c.vhdl di cui si è parlato nel precedente articolo. In tale modo ModelSim non lamenterà la mancanza della libreria ieee_proposed, seppur sia possibile crearla. Compilando il codice con un sintetizzatore con supporto per i fixed point del VHDL 2008 non sarà così necessaria alcuna modifica.

FPGA: Numeri a virgola fissa (prima parte)

Il linguaggio VHDL originariamente non prevede alcun supporto ai numeri decimali, con la ratificazione della versione VHDL-2008 si arricchisce finalmente del supporto per i numeri a virgola fissa ed a virgola mobile.

Sfortunatamente la diffusione del nuovo standard non è rapida e ancora oggi la maggior parte degli strumenti di sviluppo supporta un subset più o meno ampio di tutte le funzionalità.

Quartus e Vivado attualmente non supportano la sintesi dei numeri a virgola fissa (fixed-point) o mobile (floating-point), è però possibile scaricare da https://github.com/FPHDL/fphdl una libreria di supporto che permette di fare da ponte da VHDL-93 a VHDL-2008, permettendone così la sintesi con gli strumenti attuali.

Per poter sintetizzare i fixed point è sufficiente aggiungere al progetto i file fixed_pkg_c.vhdl e fixed_float_types_c.vhdl e dichiarare l'utilizzo del package fixed_pkg tramite

library ieee_proposed;
use ieee_proposed.fixed_pkg.all;

Vediamo in questo articolo un'introduzione ai numeri in virgola fissa e le prestazioni delle principali operazioni aritmetiche.

I numeri a virgola fissa vengono rappresentati stabilendo in una posizione ben definita la virgola, ad esempio è possibile rappresentare il valore 3,25 tramite una stringa di bit composta da 1 bit per il segno, 4 bit per la parte intera e 3 bit per la parte decimale.

00011010 rappresenterà proprio 3,25 in quanto:
- il bit 0 indicherà il segno positivo
- 0011 il valore intero 3 con la classica codifica binaria
- 010 il valore decimale 0.25 in quanto l'unità sarà suddivisa in 3 bit, quindi 2^3=8 valori ed 1/8=0.125 e di conseguenza il valore 010, 2 in codifica binaria, rappresenterà 2*0.125=0.25

Per i numeri a virgola fissa i nuovi tipi introdotti sono sfixed ed ufixed, rispettivamente per i numeri con e senza segno.

I numeri negativi sono rappresentati come usuale in complemento due, invertendo i bit ed aggiungendo 1 al risultato.

Vediamo come dichiarare un segnale di tipo sfixed:

signal x : sfixed (4 downto -3);

Tramite il range possiamo specificare come suddividere la parte intera da quella decimale.
La virgola è situata tra l'indice 0 e -1, avremo quindi 5 bit per la parte intera (compreso il bit di segno) e 3 bit per la parte decimale.

NB: E' importante ricordarsi che la parte intera comprende l'indice 0, quindi la sintassi è più semplicemente: sfixed (INTEG-1 downto -DECIM) dove INTEG è il numero di bit per la parte intera (compreso il bit di segno) e DECIM il numero di bit per la parte decimale.

Vediamo adesso un semplice blocco sommatore:



Dove in particolare, oltre a quanto abbiamo visto, notiamo che la dimensione del risultato z è superiore di un bit rispetto ai due addendi per evitare overflow (ed errori in compilazione).

Vedremo in prossimi articoli ulteriori dettagli sui fixed-point.

Concludo l'articolo con una tabella relativa alle prestazioni dei numeri a virgola fissa con segno, estratte in riferimento ad un dispositivo Cyclone V 5CEFA9F23C8, come quello presente nella scheda BEMICRO CV A9.

NB: L'occupazione di risorse logiche (ALM) è stata misurata con logica puramente asincrona mentre le frequenze massime (in MHz) sono state ottenute registrando gli ingressi e le uscite, ovvero inserendo dei flip-flop per evitare di includere nella misurazione i tempi di propagazione verso i pin esterni e poter utilizzare l'analisi statica di TimeQuest per circuiti sincroni.

I bit sono stati equamente suddivisi tra parte intera+segno e parte decimale, ad esempio se la lunghezza dati in tabella è 8 bit per operando 4 bit rappresentano parte intera e segno e 4 bit la parte decimale. La lunghezza dati del risultata varia in base al tipo di operazione eseguita per non permettere overflow.

Dalla tabella è possibile notare come le prestazioni per somma e moltiplicazione siano in linea con le prestazioni degli interi.

I blocchi DSP della FPGA in oggetto non permettono un trattamento di dati di dimensione 32x32, per questo motivo per tale operazione sono stati utilizzati più blocchi DSP.

La divisione rappresenta sicuramente la nota dolente, in quanto è sintetizzata inferendo l'IP LPM_DIVIDE senza pipeline, per prestazioni di throughput migliori è consigliabile istanziare manualmente tale blocco specificando una pipeline di profondità adeguata per la propria frequenza target o sfruttare le funzionalità di retiming di sintetizzatori in grado di spostare i flip-flop all'interno della logica di divisione, come ad esempio Synplify.

Wave Sheet

Qualche volta può essere utile riflettere con carta e penna e nel ragionare sulle forme d'onda può essere comodo disporre di un foglio predisposto appositamente per abbozzare qualche idea.

Voglio condividere con voi un template che ho creato, da stampare in orizzontale:

L'utilizzo è abbastanza intuitivo, nella riga iniziale è possibile scrivere il titolo del foglio mentre sulle righe a sinistra il nome dei vari segnali il cui contenuto sarà scritto all'interno delle forme d'onda.

Spero vi faccia risparmiare tempo e magari contribuisca ad un maggiore ordine anche con questi antichi strumenti. 

NB: Sebbene sia possibile ottenere un risultato analogo con una tabella l'aspetto è più intuitivo per degli elettronici

Scarica il template WaveSheet

FPGA: Engineering Change Orders

Sintesi dell'articolo: Modifichiamo senza una ricompilazione completa alcune parti del progetto come la frequenza di uscita del PLL tramite gli strumenti ECO di Quartus.

Durante il ciclo di sviluppo purtroppo le specifiche possono cambiare all'ultimo minuto, queste modifiche sono chiamate in gergo ECO (Engineering Change Orders) e possono  in alcuni casi essere introdotte per compensare problemi di design del sistema.

Vediamo un ipotetico caso semplificato di ECO e di come Quartus possa venirci ancora un volta incontro.

Supponiamo di avere un design su logiche programmabili ad elevata complessità, quindi con tempi di compilazione elevati, e di avere una specifica iniziale di frequenza di 300 MHz ma di aver scelto un dispositivo troppo lento per implementare a tale velocità il design. Purtroppo ci accorgiamo verso il completamento dei lavori che tale frequenza non è raggiungibile.

Il sistema, al solo scopo di facilitare la comprensione, è rappresentato semplicemente nel diagramma da un doppio moltiplicatore con pipeline.

Il design utilizza come usuale un PLL per generare la frequenza di sistema e dopo aver tanto atteso visualizziamo il fatidico Timing requirements not met da Quartus. La frequenza massima per il nostro sistema che TimeQuest riporta supera di poco i 250 MHz.

Non avendo ulteriore tempo a disposizione decidiamo di accettare 250 MHz come frequenza del nostro sistema.

La procedura "standard" richiederebbe di modificare i parametri del PLL e ricompilare il progetto, così facendo innanzitutto non è detto che la frequenza massima dopo la modifica sia sempre superiore ai 250 MHz.

E' però possibile evitare la compilazione completa, che in sistemi complessi può richiedere diverse ore, cambiando solamente le proprietà relative al PLL, vediamo come.

Nel report di compilazione del Fitter andiamo innanzitutto ad individuare la sezione PLL Usage nella categoria Resource Section, facendo click col pulsante destro sul pll scegliamo Locate Node / Locate in Resource Property Editor.

Verranno visualizzate le proprietà del PLL come mostrato nell'immagine seguente

I campi senza sfondo grigio sono modificabili, cambiamo quindi il moltiplicatore del clock da 6 a 5 nel nostro caso per ottenere un clock di uscita di 250 MHz al posto dei 300 MHz.

Il valore M del moltiplicatore verrà aggiornato di conseguenza e tutti i campi modificati verranno evidenziati in rosso.

Ricordiamo infatti l'equazione della frequenza di uscita del PLL in modalità normale:

Altre equazioni come quelle per la variazione della fase ad esempio sono reperibili nella documentazione di Altera.

Scegliamo adesso Edit / Check and Save All Netlist Changes per applicare le modifiche fatte

Dopo una breve compilazione parziale, composta dalla fase di Fitter parziale ed Assembler del file di programmazione il progetto a 250 MHz sarà pronto per essere caricato sulla FPGA  per la validazione.

Prima però eseguiamo TimeQuest per controllare se abbiamo effettivamente risolto tutti i problemi, le violazioni dei tempi di Setup sono sparite ed andando nella scheda Clocks è possibile vedere che la frequenza in uscita dal PLL è effettivamente stata modificata a 250 MHz.

Non ci rimane che provare il design a 250 MHz.

NB: TimeQuest Timing Analyzer è evidenziato di rosso perché sono presenti alcuni percorsi non vincolati nel design che però non hanno criticità per il semplice design utilizzato da esempio per illustrare le funzionalità ECO.

Quartus ci offre inoltre tramite la finestra Change Manager richiamabile dal menù View / Utility Windows che ci da un resoconto delle modifiche ECO così attuate

Lo strumento permette di esportare in file .TCL le modifiche o di riportare il tutto alla situazione originaria.

Questo flusso di sviluppo rapido è molto utile anche durante l'ottimizzazione di progetti in continua modifica per evitare di eseguire una doppia compilazione se la frequenza desiderata non è raggiungibile.

Oltre al PLL è possibile modificare altre celle elementari così come lo standard, lo slew rate ed il current strenght dei pin di I/O.

NB: A causa della differente struttura dei PLL nei dispositivi Cyclone V le funzionalità ECO non sono supportate, è possibile però utilizzare l'IP Altera PLL Reconfig come descritto nell'application notes 661 di Altera per variare i parametri del PLL a tempo di esecuzione.

FPGA: Scripting con TCL

Software EDA (Electronic Design Automation) come Quartus, Vivado, ISE e Synplify Pro utilizzato da diversi produttori di FPGA tra cui la nuova startup cinese Gowin, condividono tutti il linguaggio di scripting TCL (Tool Command Language) per l'automazione di task comuni.

Vediamo innanzitutto come creare ed eseguire un semplice script TCL con Quartus.

Creiamo un nuovo progetto e scegliamo File / New / Tcl Script File e scriviamo all'interno del nuovo file la seguente riga:

puts "Hello World"

Salviamo il file col nome hello_world.tcl ed andiamo sul menù Tools / TCL Scripts...

Si presenterà la seguente schermata, premiamo Run dopo aver selezionato il nostro script.

Un messaggio ci confermerà della corretta esecuzione dello script ma non apparirà alcun messaggio "Hello World" a video. 

Per visualizzare l'output degli script è necessario aprire la relativa finestra andando su View / Utility Windows / Tcl Console

La prima riga conterrà il comando di esecuzione del file di script, chiamato in automatico dalla pressione del pulsante Run precedentemente. E' naturalmente possibile richiamare gli script dalla console TCL scrivendo direttamente il comando source nomefile.tcl.

Sotto al comando è possibile osservare il semplice output che ha generato il nostro script.

Vediamo adesso uno script di maggiore utilità progettuale.

Spesso si ha la necessità di creare molteplici configurazioni di testbench partendo da file già esistenti, l'operazione come abbiamo visto in precedenza richiede diversi passaggi, tra cui la compilazione delle impostazioni del testbench tramite l'interfaccia grafica che è sotto riportata per referenza:

Al crescere del numero dei file l'operazione diventa meccanica e molto fastidiosa, col seguente script TCL possiamo configurare automaticamente in un attimo tutti i nostri testbench, di cui alcuni eventualmente saranno ritoccati manualmente, risparmiando ad ogni modo una notevole quantità di tempo.

Tramite il comando set assegniamo dei valori a delle variabili che potranno essere richiamati tramite la sintassi $nome_variabile.

Nel nostro caso avremo le variabili dir, ext, design_instance_name e run_sim_for a cui assoceremo dei valori fissi.

- dir specifica la cartella contenente i file di testbench

- ext specifica l'estensione dei file di testbench, se non abbiamo problemi di compatibilità con altri software come ad esempio Xilinx ISE, possiamo anche utilizzare l'estensione .vht per differenziare i file di testbench rispetto agli altri.

- design_instance_name specifica il nome dell'istanza sotto test, naturalmente tutte le istanze nei testbench dovranno chiamarsi allo stesso modo.

- run_sim_for specifica il tempo di esecuzione, al pari del campo "End simulation at" nella finestra di dialogo di Quartus sopra mostrata.

E' altresì importante che nei testbench il nome della "entity vuota" corrisponda al nome del file per un corretto funzionamento di questo script. Per necessità diverse è possibile partire da questo script per modificarlo comunque a piacere.

Nelle righe seguenti avviene una ricerca dei file con l'estensione scelta nella cartella specificata dopodiché per ogni file viene estratto il nome senza estensione ed utilizzato per il richiamo dei comandi set_global_assignment specifici di quartus per l'impostazione dei testbench.

Altri EDA dispongono di comandi specifici per l'automazione di diversi task, è necessario quindi consultare la documentazione di ogni software specifico per tali comandi.

NB: Il file .qsf associato al progetto Quartus è a tutti gli effetti uno script TCL creato automaticamente tramite l'interfaccia del programma durante il normale utilizzo, aprendo il file con un editor di testo è possibile visualizzare i comandi per incorporarli nei propri script, se non si vuole ricorrere alla documentazione di Scripting.

Scarica il file materiale dell'articolo

Buona automazione con gli script TCL

FPGA: Xilinx ISE ed Internet Explorer 11

Oggi vediamo una piccola fix per risolvere un problema che può nascere nel tool di sviluppo Xilinx ISE e nei suoi accessori.

Seppur il software ISE sia ormai superato da Vivado è ancora necessario per poter sviluppare per famiglie di dispositivi come Spartan-6, Virtex-6, Coolrunner e le generazioni precedenti.

Un problema che può verificarsi (verificato su Windows 7) dopo l’aggiornamento di Internet Explorer all’ultima versione è la mancanza di funzionamento di ChipScope Inserter ed ChipScope Pro Analyzer con messaggi di errore come “Can't load ..\..\java6\nt\jre\bin\client\jvm.dll.”

Per risolvere la problematica aggiungiamo nella variabile d’ambiente PATH i seguenti valori se non presenti:

C:\Xilinx\14.7\ISE_DS\ISE\\lib\nt;C:\Xilinx\14.7\ISE_DS\ISE\\bin\nt;C:\Xilinx\14.7\ISE_DS\ISE\bin\nt;C:\Xilinx\14.7\ISE_DS\ISE\lib\nt;C:\Xilinx\14.7\ISE_DS\ISE\..\..\..\DocNav;C:\Xilinx\14.7\ISE_DS\PlanAhead\bin;C:\Xilinx\14.7\ISE_DS\EDK\bin\nt;C:\Xilinx\14.7\ISE_DS\EDK\lib\nt;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\powerpc-eabi\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnuwin\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\arm\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\linux_toolchain\nt_be\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\linux_toolchain\nt_le\bin;C:\Xilinx\14.7\ISE_DS\common\bin\nt;C:\Xilinx\14.7\ISE_DS\common\lib\nt;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\

E’ anche possibile creare una variabile dell’utente al posto della variabile di sistema per risolvere in modo ancora più rapido ed evitare di controllare tutti i percorsi esistenti.

Dove è possibile naturalmente adattare alla propria versione di ISE i PATH e rimuovere il percorso per la versione Java di Oracle se non installata.

Cyclone V SoC: Ethernet senza router con DE1-SoC

La documentazione di Terasic per la DE1-SoC è ben fatta e seguendo il manuale e gli esempi si sarà in grado di programmare il processore ARM, usare l'area logica programmabile e capire l'interazione tra queste due componenti.

Sul sito web è presente un'immagine pronta all'uso di un sistema Linux Console che è possibile scrivere su una scheda MicroSD da almeno 4GB come descritto nella DE1-SoC Getting Started Guide o nel tutorial Using Linux on the DE1-SoC.

Riassumendo è necessario:
- preparare la MicroSD ed inserirla nella DE1-SoC
- impostare tutti i dip switch sul retro della scheda su OFF per configurare la FPGA dal processore ARM all'avvio
- accendere il sistema
- collegare il cavo micro USB al PC
- Utilizzare programmi come Putty per aprire un terminale con la DE1-SoC

Nell'immagine la configurazione di default (AS) della scheda una volta aperta dalla scatola e sotto le varie configurazioni possibili, da notare l'ordine [4:0] utilizzato nella tabella

 

 

L'utilizzo del cavo USB può però essere sostituito dal cavo Ethernet, che utilizzeremo anche per la comunicazione col pc nelle nostre applicazioni nei prossimi articoli. Il vantaggio principale è la maggiore velocità di comunicazione raggiungibile tramite Ethernet, la scheda supporta infatti la velocità Gigabit contro i 115200 bps della seriale.

 

Nella documentazione di Terasic, nel documento My_First_HPS, è mostrato un esempio di configurazione con router, il che toglie però un po' di praticità al tutto in quanto necessario router con alimentatore, due cavi ethernet, etc..

 

Avere sottomano un router gigabit non è poi cosa scontata vista l'ampia diffusione di router a 10/100 Mbps. E' sicuramente più comune invece avere solamente un portatile con scheda di rete Gigabit.

 

NB: Per l'utilizzo della velocità Gigabit è importante avere un cavo CAT5e o superiore di buona qualità. Cavi non adatti avranno impatto sulla velocità della comunicazione.

 

 

 

Vediamo come rendere il nostro ambiente più snello collegando direttamente il pc alla scheda con un singolo cavo ethernet.

 

Una volta collegati alla DE1-SoC da terminale (tramite USB) digitiamo:

 

vi /etc/network/interfaces

 

per editare il file di configurazione delle interfacce di rete tramite il programma testuale vi.

Ricordo che vi ha due modalità di funzionamento: inserimento e comandi.

Inizialmente il programma è in modalità comandi, premiamo "i" per passare alla modalità inserimento ed inseriamo:

iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
broadcast 192.168.0.255

al posto di

iface eth0 inet dhcp

che possiamo semplicemente commentare ponendo il cancelletto (#) all'inizio della riga.

Dopodichè premiamo ESC per tornare in modalità comandi e scriviamo ":wq" (senza virgolette) e battiamo invio per salvare ed uscire.

Così facendo utilizzeremo un IP statico al posto di un IP dinamico che senza un router è "macchinoso" assegnare. Riavviamo tramite il comando "reboot" la DE1-SoC.

Nella scheda di rete sul pc, collegata alla DE1-SoC, impostiamo invece i seguenti parametri

 

La configurazione è terminata, adesso sarà possibile accedere alla DE1-SoC senza router tramite l'IP 192.168.0.3, tramite SSH per esempio, mentre il PC avrà IP 192.168.0.2.

 

E' naturalmente possibile adattare gli indirizzi IP in base alle proprie esigenze, è importante che non ci siano conflitti con altri indirizzi IP presenti nella vostra rete.

 

Vedremo nel prossimo articolo come configurare DS-5 per navigare il filesystem tramite SFTP ed il terminale SSH integrato per evitare di tenere aperti più programmi durante lo sviluppo, proprio con la sola connessione ethernet così configurata.

Cyclone V SoC: Gli strumenti di sviluppo per ARM

La scheda DE1-SoC come dice il nome e come abbiamo già anticipato, include un SoC (System On Chip) composto da una logica programmabile FPGA ed un processore ARM in un unico chip.

Diamo ora uno sguardo a quali sono gli strumenti di sviluppo per questo nuovo SoC.

La FPGA è programmabile come di consueto tramite Quartus II, il processore ARM necessita invece dell'installazione della SoC Embedded Design Suite (SoC EDS), una suite di sviluppo disponibile anch'essa come Quartus nella versione gratuita Web Edition o nella versione a pagamento Subscription Edition.

La differenza principale è la possibilità nella versione a pagamento di sviluppare bare-metal, ovvero di programmare il processore al livello più basso, senza un sistema operativo, e di utilizzare il compilatore di casa ARM. Generalmente se si necessità di funzionalità avanzate come la comunicazione di rete si opta per un sistema dotato di un sistema operativo, lo sviluppo bare-metal è quasi sempre relegato ad applicazioni real-time dove è necessario un determinismo maggiore.

La versione gratuita limita lo sviluppo ad applicazioni Linux/Android tramite GCC ma in molti casi questo non rappresenta un grosso limite. Lo sviluppo bare-metal di processori complessi come l'ARM Cortex A9 non è "consigliato" nei progetti più comuni mentre può avere più senso sviluppare applicazioni e driver specifici per Linux.

Per un elenco completo delle differenze tra le due versioni rimando alla pagina ufficiale.

Vediamo adesso cosa include il SoC EDS:






- ARM DS-5: l'ambiente di sviluppo basato su Eclipse che include praticamente tutto quello di cui si ha bisogno per lo sviluppo di applicazioni basate su Linux.

 

- Hardware Libraries: librerie di basso livello denominate HWLIB che contengono API per l'utilizzo dei GPIO, I2C, SPI, etc.. per il solo sviluppo bare-metal

 

- Configuration Tools: tool come il Device Tree Generator utili per il solo sviluppo bare-metal

 

- Examples: esempi, quasi tutti per lo sviluppo bare-metal.

 

Come è possibile intuire utilizzeremo sostanzialmente il solo ARM DS-5 con il compilatore GCC incluso nell'installazione.

L'utilizzo del compilatore GCC in ambiente Windows non è consigliato da Altera e presenta problemi non presenti nella versione Linux. Ad esempio nella versione attuale (GCC 4 inclusa in DS-5) si hanno problemi di compilazione con programmi contenenti istruzioni NEON. E' quindi consigliabile innanzitutto installare SoC EDS su un sistema Linux in caso di problemi.

E' da notare che è possibile utilizzare il compilatore gratuito GCC per lo sviluppo bare-metal anche senza l'utilizzo di DS-5, tramite makefile per esempio, anche se vedremo solamente lo sviluppo di applicazioni Linux sul processore ARM, lasciando a chi volesse intraprendere lo sviluppo bare-metal alla corposa documentazione disponibile.

FPGA: Cyclone V SoC e DE1-SoC

La DE1-SOC è una scheda di sviluppo prodotta da Terasic per poter progettare rapidamente con le FPGA Cyclone V SE con processore ARM Cortex-A9 dual-core di cui parleremo ancora prossimamente.

La nuova serie Cyclone V è divisa in ben sei varianti diverse:

La dev-board in oggetto è equipaggiata col modello 5CSEMA5F31C6 di cui sono riportate sotto le risorse principali:

Come abbiamo visto nell'articolo precedente in questa nuova serie di FPGA le risorse logiche sono rappresentate in prima istanza dagli ALM, seppur vengano ancora riportati i LE per un confronto rapido con le vecchie serie.

Rispetto alla scheda DE0-Nano, utilizzata nei precedenti articoli, abbiamo risorse logiche quasi quattro volte maggiori (22k LE contro 85k LE), per design di complessità maggiore.

La memoria integrata nelle FPGA (SRAM) sta rapidamente aumentando generazione dopo generazione, ne troviamo a disposizione 4450 Kbit (0.5 MBytes circa) tra blocchi M10K e MLAB.

I blocchi M10K sono blocchi di memoria dedicati da 10 Kbit mentre il 25% degli ALM è configurabile come memoria distribuita (similarmente a quanto avviene nelle FPGA Xilinx) usando gli MLAB da 640 bit.

Facendo un rapido conto 480 Kbit di MLAB totali vogliono dire 768 MLAB da 640 bit, il 25% degli ALM è circa 8018 ALM, quindi approssimando un MLAB è realizzato da fino a 10 ALM, come infatti viene descritto nella documentazione. Quindi ogni ALM "ibrido" contribuisce con ben 64 bit, rispetto ai 4 bit presenti negli ALM "ordinari".

Rispetto alla serie Cyclone IV gli MLAB (già presenti su altre serie di fascia più alta) sono una interessante novità per ottimizzare la creazione di piccole memorie come registri a scorrimento, piccole FIFO, etc.

Continuando la lettura della tabella ogni Variable-precision DSP può implementare due moltiplicatori a 18x18 bit con accumulatore, ma può essere configurato anche diversamente, per implementare un singolo moltiplicatore 27x27 bit con accumulatore ad esempio. Anche in questo caso il numero di moltiplicatori 18x18 è riportato per confrontare rapidamente il dispositivo con vecchi modelli.

Con HPS si intende Hard Processor System, ovvero il processore ARM integrato. Il vantaggio principale rispetto a soluzioni discrete (ovvero un chip per la FPGA ed un chip per il processore ARM, collegati tramite piste su pcb) è sicuramente la riduzione del BOM (Bill of Materials) ma anche sotto il profilo prestazionale una connessione molto veloce tra la FPGA e l'ARM con bande fino a 128 Gbps di picco.

Seppur l'integrazione comporti risparmi sul fronte economico ed energico un possibile svantaggio è la riduzione dell'area dissipabile termicamente. Con due package è possibile montare due sistemi di dissipazione del calore distanti e quindi non interferenti significativamente, ad esempio due dissipatori passivi se il calore generato non è molto, mentre con un unico package lo spazio è minore e quindi le difficoltà ad estrarre il calore sono maggiori. Resta da valutare per la propria applicazione quindi se il power-saving e quindi il minor calore generato dovuto all'integrazione riesce a compensare la maggior difficoltà di mantenere il chip nelle migliori condizioni operative.

HPS e FPGA sono messi in comunicazione tramite dei canali dedicati, alcune risorse come alcuni PLL, I/O e Hard Memory Controller sono collegati direttamente all'HPS, altri alla parte FPGA del chip come è possibile notare dalla tabella sopra.

Ricordo però che tramite i canali di comunicazione è possibile però sfruttare ad esempio gli I/O HPS dalla parte FPGA, anche se ciò richiede un'apposita configurazione.

Lo standard LVDS o comunque gli altri standard differenziali purtroppo non sono utilizzabili in modo sicuro su questa scheda di sviluppo perché la tensione degli I/O, VCCIO, è fissata a 3.3v mentre lo standard LVDS prevede solamente tensioni da 2.5v, per comunicazioni seriali ad alta velocità è necessario guardare ad altre schede di sviluppo, con connettori appositi per l'alta velocità, resistenze di terminazione, linee con impedenze controllate, etc..

Lo speed-grade della FPGA è il più veloce (-6), ideale per ridurre le problematiche di tempistiche e creare design ad elevate frequenze.

Come abbiamo potuto accennare nel precedente articolo la dissipazione del calore può presentare un problema, un semplice design di esempio (come un semplice sommatore ad 8 bit) mostra infatti una Core Static Thermal Power Dissipation stimata in condizioni tipiche di circa 411 mW mentre nelle condizioni peggiori 538 mW.

La scheda prevede il montaggio di un dissipatore con eventuale ventola tramite due fori posti a circa 55 mm lungo la diagonale del chip principale.

E' anche predisposta per un connettore a 3 pin per il collegamento della ventola, di cui però solamente due sono collegati come mostra lo schema seguente.

Dove DNI indica Do Not Installed, ovvero il componente non è presente ma è possibile acquistarlo ed aggiungerlo in quanto predisposto il pcb.

SM2T3V3A è un diodo di protezione TVS unidirezionale, per cortocircuitare a massa segnali con tensioni al di fuori del range [-0.3v,3.6v] circa che potrebbero danneggiare la delicata FPGA.

FDV305N è un NMOS utilizzato in saturazione (come interruttore) per accendere e spegnere la ventola dalla FPGA.

Visto il calore che anche i design di prova forniti da Terasic generano ho provveduto subito al montaggio di un dissipatore con ventola per rimanere sul lato sicuro.

Per non invalidare la garanzia o comunque avere possibili problemi nella sostituzione visto che la scheda è arrivata da poche settimane, non ho installato il connettore ed i componenti aggiuntivi per collegare la ventola ma ho preferito alimentarla esternamente quando necessario.

Il vantaggio è anche che così facendo è possibile regolare la tensione della ventola e non è necessario modificare i progetti pre-esistenti per l'attivazione del pin della ventola se necessario.

Sotto un immagine del risultato finale ed alcuni consigli

- Montando due piccoli distanziali aggiuntivi sul lato inferiore del PCB (sono presenti solo 4 distanziali inferiori) è possibile aumentare la resistenza meccanica della scheda. Porre comunque leggerezza durante operazioni di avvitatura/svitatura. 

- Tra FPGA e dissipatore stendere un sottile strato di pasta termoconduttiva di buona qualità

- Per rimuovere il dissipatore dopo aver rimosso i push-pin non tirarlo verso l'alto ma farlo ruotare per staccare la pasta termoconduttiva, per evitare di esercitare pressioni tali da rompere il package della FPGA.

- Per non perdere di estetica e mantenere la possibilità di installare il pannello in plexiglass sostituire i quattro distanziali superiori (stand-off) con alcuni leggermente più alti in base all'altezza della ventola. Ho utilizzato una ventola con dissipatore a basso profilo per far rientrare comunque il tutto nella busta antistatica e nella scatola originale .

- Porre attenzione alla pressione esercitata da dissipatori con push-pin, regolare le molle per non applicare tensioni fuori dalle massime supportate dal package BGA.

In alternativa è possibile utilizzare dei dissipatori passivi generici (senza ventola), magari a basso profilo se adeguati alla dispersione del calore prodotto, con un thermal pad per una rapida sostituzione.

Ho inoltre applicato un piccolo dissipatore (7x7x4mm) sul piccolo integrato che è possibile vedere in foto sopra. Si tratta dell'Ethernet transceiver siglato ksz9021rl che durante l'utilizzo intensivo con trasmissioni Gigabit Ethernet diventa discretamente caldo.

Buona sperimentazione in sicurezza.

Novità dal settore delle FPGA

E' passato qualche mese dall'ultimo post, il tempo purtroppo è sempre tiranno ma spero di poter scrivere con maggiore frequenza nelle prossime settimane.

Intel ha annunciato l'acquisizione di Altera il primo di Giugno e come coincidenza i prezzi delle FPGA stanno rapidamente calando nelle ultime settimane come è possibile notare dai prezzi delle nuove schede di sviluppo BeMicro CV A9 (149$) e Nexys Video di Digilent (499$, Academic 299).

BeMicro CV A9	Nexys Video

La peculiarità di queste schede di sviluppo è la FPGA particolarmente capiente di cui sono dotate, per la precisione montano entrambe il modello più grande delle serie low-cost di Altera e Xilinx rispettivamente e dispongono di strumenti di sviluppo gratuiti (Quartus di Altera a partire dalla versione 15.0 e Vivado di Xilinx).

Senza analizzare nel dettaglio le caratteristiche di entrambe le schede (memorie, connettori di I/O, etc..) reperibili comunque sui siti dei prodotti, vediamo meglio le caratteristiche delle FPGA.

Cyclone V

La BeMicro CV A9 monta il chip Cyclone V E (Enhanced logic/memory) di casa Altera, la serie Cyclone V è la prima di Altera ad integrare un processore ARM assieme alla logica programmabile, nella variante offerta però non è presente l'ARM il che si traduce però in costi minori e minore potenza statica dissipata. E' comunque possibile istanziare soft-core Nios II che seppur meno performanti possono risultare più semplici per personalizzazioni.

Il codice della FPGA è 5CEFA9F23C8N, sotto è invece mostrato un riepilogo delle risorse offerte

Lo speed-grade 8 purtroppo è il più lento il che limita la frequenza massima raggiungibile rispetto alla versione più veloce con speed-grade 6.

Per avere un'idea delle differenze prestazionali tra i vari speed-grade sono sotto riportate per comodità alcune tabelle tratte dal datasheet

Le prestazioni ottenibili dipendono naturalmente dal proprio design e le tabelle indicano le prestazioni massime per i vari blocchi.

La grande disponibilità di elementi logici (LE), di moltiplicatori e di tutte le altre risorse "compensa" però molto bene in molte applicazioni lo speed-grade più lento.

In realtà i LE sono stati sostituiti dagli ALM (Adaptive Logic Module), utilizzati in precedenza dai dispositivi di fascia più alta.

Riassumendo molto rapidamente la nuova struttura per i Cyclone V prevede un ingresso ad 8 ingressi frazionabile, due addizionatori completi per la modalità aritmetica e quattro registri dedicati.

I LE vengono però riportati solo per un rapido confronto con i modelli precedenti ed all'incirca 1 ALM ~= 2.6 LE anche se è bene provare a compilare il proprio design per vedere l'effettivo utilizzo di ALM.

E' bene ricordare però che con maggiori elementi logici aumenta (o ALM) il consumo statico di potenza rispetto a device "più piccoli".

Stando a Quartus per il device montato nella scheda di sviluppo in oggetto abbiamo una Core Static Thermal Power Dissipation di circa 521 mW in condizioni tipiche e di circa 706 mW nelle condizioni peggiori.

NB: Con la serie Cyclone V è importante stimare il consumo di potenza tramite le caratteristiche di potenza massime, ovvero nel peggior caso possibile in quanto essendo ottimizzata per il basso costo per raggiungere la massima resa produttiva possibile la "finestra passante" è stata espansa per la massima potenza statica. Il processo produttivo 28nm LP (Low Power) sta migliorando e col tempo le prestazioni miglioreranno avvicinandosi maggiormente ai consumi tipici, è sempre meglio però stare sul lato sicuro. Fonte: alteraforum

Nei Settings del progetto in Quartus è consigliato impostare a Maximum il valore di Device power characteristics.

L'aggiunta di un dissipatore può essere un buon investimento per prototipare con maggiore tranquillità senza preoccuparsi troppo dei consumi di potenza in piccoli design, al crescere della frequenza e delle risorse utilizzate è necessario eseguire un'analisi più completa tramite PowerPlay Power Analyzer impostando correttamente il tasso di variazione dei segnali (toggle rate).

Per la scelta del dissipatore ricordo che il package della FPGA montata ha dimensioni di 23x23mm.

E' da tenere presente però che la scheda non offre un connettore dedicato per poter collegare una eventuale ventola.

Tutto sommato per molte applicazioni la scheda fornisce un punto di accesso rapido ed economico alla sperimentazione con logiche programmabili di buona capacità.

Per finire la possibilità di impostare la tensione di I/O tramite jumper a 3.3v o 2.5v permette di sfruttare lo standard LVDS per creare sistemi di calcolo basati su array di questa schede comunicanti tra loro ad alta velocità.

Non sono purtroppo disponibili esempi sul sito del produttore per la programmazione della scheda, informazioni aggiuntive posso essere reperite presso Altera Wiki.

Artix-7

La Nexys Video è invece una scheda di sviluppo per le FPGA Artix-7 di Xilinx, il modello XC7A200T-1SBG484C montato è il più generoso della serie.

Come si può evincere dal nome è pensata per l’ambito videoludico

Sotto è riportata la tabella delle principali risorse che offre:

E' da ricordare però che non è possibile un confronto diretto tra Celle Logiche Xilinx utilizzate ed Elementi Logici di Altera a causa dello loro differente strutturali.

Una peculiarità rispetto ad Altera è la presenza di un’interfaccia analogica XADC inclusivo di ADC doppio a 12 bit e 1 MSPS ed un sensore di temperatura interno con una precisione di +/- 4°C nelle condizioni operative più comuni, sempre più utile visto l’elevato calore che i dispositivi più grossi possono generare.

Rispetto al modello di FPGA analizzato precedentemente abbiamo inclusi 16 GTP (Low-Power Gigabit Transceivers) fino a 3.75 Gbps, disponibili solamente con le varianti GX della serie Cyclone V.

A presto.

NB: I prezzi delle schede di sviluppo sono da intendersi senza IVA, trasporto ne spese doganali.