venerdì 3 luglio 2015

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.

lunedì 29 giugno 2015

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 Vivando 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).

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à.

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.

mercoledì 19 marzo 2014

Come iniziare con gli IC Cypress EZ-USB FX2LP

Questo articolo vuole essere una collezione di risorse per iniziare lo studio dei circuiti integrati di casa Cypress, precisamente gli IC della serie FX2LP.

Qualora fosse necessario disporre di comunicazione USB 2.0 Hi-Speed (480 MBps) e di un microcontrollore ad 8 bit ad elevate prestazioni, IC come CY7C68013A (sotto è mostrato il suo diagramma a blocchi logico) che utilizzeremo nell’articolo sono sicuramente da valutare.

FX2LP

Notiamo come sul dispositivo in considerazione non sia presente una memoria Flash o EEPROM interna per la memorizzazione del firmware, da un punto di vista produttivo significa ridurre di molto l’area di silicio e quindi il costo del dispositivo non dovuto solo alla area della memoria ma anche alla pompa di carica (Charge Pump) interna necessaria per la generazione della elevata tensione necessaria per il suo utilizzo.

La pompa di carica introduce problemi legati alla miniaturizzazione del dispositivo ed influisce spesso sulla scelta del processo produttivo, di contro per la memorizzazione del firmware sarà necessaria una memoria esterna o il caricamento del firmware in memoria RAM al collegamento del PC tramite USB, scelta perseguita in diversi prodotti commerciali che rende allo stesso tempo molto semplice l’aggiornamento del firmware.

E’ possibile utilizzare una EEPROM esterna da 16 bytes come l’IC 24LC00 per la sola memorizzazione del VID/PID USB associato al dispositivo in modo da far associare subito il driver desiderato al dispositivo.

Il micro nell’IC è compatibile a livello di codice binario con gli 8051 classici e permette di riutilizzare toolchain e strumenti come Keil uVision C51 per lo sviluppo del codice. E’ necessario prestare attenzione ad alcuni dettagli in quanto la maggiore velocità (4 clock / istruzione) rispetto all’architettura classica (12 clock / istruzione) può introdurre differenze nelle tempistiche di funzionamento. Nel panorama Open Source è disponibile il compilatore SDCC (Small Device C Compiler).

Sulla rete sono disponibili diverse schede di sviluppo per tutte le tasche, dalle economiche schede amatoriali CY7C68013A MINI BOARD ai kit di sviluppo ufficiali come il CY3684 EZ-USB FX2LP Development Kit contenente al suo interno oltre all’IC anche SRAM, GAL, IO Expanders, diverse EEPROM, Transceiver, e molto altro ancora.

Per quanto riguarda la programmazione non è necessario comperare un programmatore esterno in quanto grazie alla interfaccia USB è possibile caricare il firmware da PC nella RAM o nella EEPROM collegata all’IC.

Per iniziare, anche nel caso di schede di sviluppo economiche, installiamo il software di sviluppo CY3684 EZ-USB FX2LP Development Kit che creerà diverse cartelle nel nostro disco.

dir

In particolare è importante la cartella Drivers\cyusbfx1_fx2lp in quanto sarà necessario installare il driver ivi contenuto al collegamento del dispositivo al PC tramite USB. Dopo l’installazione del driver verrà identificato come Cypress EZ-USB FX2LP No EEPROM e sarà pronto per l’interfacciamento coi tools di sviluppo.

gest

Apriamo la Cypress USB Console, installata assieme al Development Kit per verificare che il driver del dispositivo sia correttamente installato

Cy USB Console

Scegliendo Options / EZ-USB Interface è possibile accedere ad altri comandi per il caricamento di firmware (pulsante Download per il caricamento del firmware nella RAM), scrittura della EEPROM collegata al dispositivo  (pulsante S/Lg EEPROM per la scrittura di piccole o grosse memorie EEPROM, S = Small, Lg = Large) ed altro ancora.

EZ-USB Interface

L’interfaccia del programma non è purtroppo molto user-friendly, è consigliato consultare la guida EZ-USB Development Kit User Guide per maggiori informazioni sugli strumenti di Cypress.

Realizziamo adesso un semplice programma programmando il microcontrollore 8051.

Apriamo Keil uVision5, disponibile anche in versione di valutazione gratuita con qualche limitazione, e scegliamo Project / New uVision Project indicando il percorso del nostro progetto. Ci verrà chiesto il dispositivo da programmare, scegliamo EZ-USB FX2LP (CY7C68XXX-X) e premiamo OK.

dev

Scegliamo adesso Projects/Options for Target e dalla scheda Target impostiamo la frequenza di clock del cristallo della nostra scheda di sviluppo

opt target

Nella scheda Output assicuriamoci che sia abilitata la creazione del file HEX

opt out

Nella scheda Utilities infine impostiamo come strumento di programmazione del dispositivo il percorso del programma CyUpload, scaricabile al termine dell’articolo, che ho sviluppato tramite le libreria Cypress CyUSB .NET DLL di cui parleremo eventualmente in un successivo articolo, per semplificare, integrare e velocizzare la programmazione ed evitare di ricorrere al programma Cypress USB Console ogni volta.

opt util

Nel campo Arguments inseriamo la stringa %H che sarà trasformata automaticamente nel percorso del file HEX durante la programmazione da parte di Keil uVision.

Adesso che il progetto è stato correttamente configurato, aggiungiamo al progetto nel Source Group 1 la libreria EZUSB.LIB dal percorso C:\Cypress\USB\CY3684_EZ-USB_FX2LP_DVK\1.0\Target\Lib\LP per poter utilizzare funzioni come EZUSB_Delay() per l’attesa di un certo numero di millisecondi.

Creiamo adesso un nuovo file Blink.c col seguente codice:

keil

Dove OEB è il registro della porta B adibito alle direzioni dei pin (1 = Output, 0 = Input) ed IOB è il registro di I/O per la lettura e scrittura dei bytes.

Il codice mostrato alzerà il pin PB0 ad HIGH per 50ms e lo porterà a LOW per 100ms, ripetendo il codice ciclicamente.

Una volta terminata la stesura del codice è possibile compilare il programma con il comando Project / Build target e caricarlo nel dispositivo tramite il comando Flash / Download

Variando i tempi di lampeggio e collegando un led con relativa resistenza sarà possibile creare il classico Hello World del mondo della programmazione firmware.

Abbiamo visto in questo articolo alcuni strumenti e un esempio di programmazione dei dispositivi Cypress,

L’Application Note Getting Started with FX2LP può fornire un’introduzione preliminare alternativa, il punto di inizio per lo studio del microcontrollore e delle funzionalità USB dell’IC è il manuale di riferimento tecnico EZ-USB Technical Reference Manual ed il datasheet del dispositivo.

E’ possibile continuare il proprio studio esplorando funzionalità avanzate come l’USB Hi-Speed, i GPIF, e tanto altro ancora.

Importante: Il programma CyUpload è una utility pensata per l’uso personale e non ampiamente testata per funzionare in tutte le condizioni possibili. Programma la RAM del primo dispositivo utilizzante i driver Cypress trovato, è necessario collegare solamente il dispositivo Cypress da programmare o utilizzare Cypress USB Console che può essere utilizzato per controllare se sono presenti altri dispositivi Cypress collegati.

Scarica CyUpload

Buon divertimento con i circuiti Cypress

domenica 16 marzo 2014

FPGA: Comunicazione ad alta velocità tramite USB 2.0 - Download

Siamo giunti al termine di questa triologia di articoli dove abbiamo realizzato una comunicazione ad alta velocità tra FPGA e PC, è sotto riportato il sommario del percorso svolto:

Prima parte:       Introduzione al progetto e UM232H

Seconda parte:  DE0-Nano

Terza parte:       Software

Nel download del progetto è presente:

- il progetto per la realizzazione del modulo USB 2.0 per la DE0-Nano tramite toner transfer (Eagle 6.4)

- il progetto console C# (Visual Studio 2010)

- il progetto FPGA (Quartus 13.0)

de0-nano usb 2.0 board

Per concludere volevo segnalare alternative all’IC FT232H di cui esistono versioni a più canali denominate FT2232H (2 canali) ed FT4232H (4 canali) utili quando nella scheda sono necessarie contemporaneamente più interfacce come ad esempio JTAG per la programmazione della FPGA.

Infine gli integrati di Cypress della serie EZ-USB SX2 offrono un controller USB 2.0 ad alta velocità mentre la serie FX2LP (FX2 Low Power) aggiunge nello stesso integrato un microcontrollore 8051 e tante altre funzionalità.

La scelta per questi articoli è però ricaduta sull’FT232H tramite il modulo di sviluppo UM232H per la sua semplicità e il basso costo.

Buon divertimento a tutti

FPGA: Comunicazione ad alta velocità tramite USB 2.0 (terza parte) - Software

L’IC FT232H di cui abbiamo parlato nei precedenti articoli (parte I, parte II) permette una comunicazione col pc tramite due interfacce: VCP e D2XX.

L’interfaccia VCP (Virtual COM Port) è pensata per sostituire sistemi con la vecchia porta seriale senza modifiche nei software esistenti, il dispositivo viene visto dal sistema operativo come una porta COM seriale. Gli svantaggi di questa interfaccia riguardano le prestazioni, difficilmente si riusciranno a superare i 3M Baud.

L’interfaccia D2XX è un’interfaccia proprietaria per i dispositivi FTDI che permette di raggiungere le massime prestazioni e fornisce accesso a tutte le funzionalità esposte dagli IC.

cdm
Windows CDM Driver Architecture

Nella distribuzione Windows entrambe le interfacce vengono fornite in un unico pacchetto driver denominato CDM (Combined Driver Model) mentre per gli altri sistemi operativi le interfacce corrispondono a differenti driver mutualmente esclusivi.

Dopo aver installato il driver CDM è possibile procedere alla programmazione tramite D2XX utilizzando le API documentate nella D2XX Programmer's Guide e visionando gli esempi nei diversi linguaggi di programmazione.

Per semplificare la comprensione del software svilupperemo in questo articolo un programma console per scrivere e leggere i dati dalla FPGA.

Come ulteriore facilitazione utilizzeremo il linguaggio C# tramite la libreria wrapper fornita da FTDI per velocizzare ulteriormente i tempi di sviluppo.

La libreria incapsula nella classe FTDI tutte le funzionalità esposte dalle API, aggiungendo una serie di controlli e diagnostica per rendere più developer-friendly l’utilizzo a programmatori C#.

Importante: Alcuni messaggi di errore vengono mostrati dalla libreria wrapper tramite MessageBox, sarà necessario includere nel progetto il riferimento all’assembly System.Windows.Forms per poter compilare correttamente l’applicazione se si include il sorgente della libreria nel proprio progetto per evitare di distribuire una DLL aggiuntiva.

Per avere accesso al dispositivo come prima cosa dobbiamo creare una nuova istanza della classe FTDI e aprire il dispositivo.

code1

La prima funzione da chiamare sarà OpenByDescription, OpenByIndex, OpenByLocation o OpenBySerialNumber dove sarà possibile aprire il dispositivo in base alla descrizione, indice, locazione o numero di serie.

Utilizzeremo OpenByDescription specificando la descrizione “UM232H”, corrispondente alla descrizione di default del modulo. In caso di problemi sarà possibile impostare il nome della descrizione del chip tramite il programma FT Prog. La stringa della descrizione è memorizzata nella EEPROM collegata al chip FT232H sul modulo UM232H.

La libreria offre un meccanismo un po’ antico per la gestione degli errori che non è stato convertito nella libreria wrapper con l’utilizzo di eccezioni C#. Ogni chiamata in genere restituisce un valore di tipo FT_STATUS, da controllare per verificare se tutto è andato a buon fine.

Prima di poter leggere e scrivere dati dobbiamo impostare la modalità operativa di comunicazione ed alcuni parametri.

code2

Innanzitutto resettiamo il dispositivo chiamando la funzione SetBitMode con modalità FT_BIT_MODE_RESET, ignoriamo il primo parametro che consiste in una maschera di bit per impostare quale bit sono di ingresso e quali di uscita, parametro utile per configurare i pin di I/O dell’ACBus.

Dopo il reset attendiamo 10ms per impostare il dispositivo nella modalità 245 FIFO sincrona tramite il parametro FT_BIT_MODE_SYNC_FIFO.

Impostiamo poi altri parametri come la latenza tramite SetLatency il cui valore di default è 16ms. Il timer di latenza è una caratteristica del driver, un timeout per trasmettere brevi pacchetti di dati al pc. Cambiare la latenza è un’operazione opzionale e può servire per migliorare in alcuni casi le prestazioni in base alla propria applicazione.

Tramite InTransferSize impostiamo la dimensione dei trasferimenti in ingresso ed uscita dell’USB, aumentiamo questo valore per migliorare le prestazioni nel trasferimento sequenzialmente di grosse quantità di dati.

Infine impostiamo tramite SetFlowControl il flusso di controllo a FT_FLOW_RTS_CTS per evitare rari errori di corruzione dati.

Siamo adesso pronti a trasferire ad alta velocità i nostri bit.

Senza riportare tutto il codice sorgente che potrete trovare alla fine di questo articolo, riportiamo le parti salienti descrivendo a grandi linee il resto.

Come prima operazione apriamo il file di ingresso da trasmettere alla FPGA, ne leggiamo un blocco composto da qualche migliaia di bytes e tramite la funzione Write inviamo all’IC FT232H i bytes letti che verranno quindi inviati alla FPGA.

code3

La funzione write è molto semplice e così dichiarata:

code5

dove il primo parametro è il buffer contenente i dati da scrivere, il secondo parametro indica il numero di bytes da scrivere ed il terzo riporta i bytes effettivamente scritti.

swWrite è un’istanza della classe C# Stopwatch per misurare la durata dell’operazione e permettere di riportare successivamente le statistiche di velocità delle operazioni.

Dopodiché leggiamo i dati dalla FPGA utilizzando la funzione Read:

code4

Con sintassi analoga alla funzione Write, molto semplice da utilizzare. Ricevuti i dati controlliamo byte per byte se corrispondono ai dati del file inviato ed aggiorniamo ad intervalli regolari le statistiche.

Sotto è riportata una schermata del programma in esecuzione:

console

In questo articolo è stata sviluppata una semplice interfaccia console per evitare di aggiungere le complessità di un interfaccia grafica multithreading mostrando le operazioni basilari da compiere per gestire la comunicazione tramite USB 2.0ad alta velocità con il chip di FTDI.

Importante: Prima di lanciare l’applicazione è necessario inserire nella cartella contenente l’eseguibile (cartella Debug o Release) un file nominato dataIn.bin che sarà inviato alla FPGA ed il cui contenuto sarà ricevuto indietro

sabato 1 marzo 2014

FPGA: Comunicazione ad alta velocità tramite USB 2.0 (seconda parte) - DE0-Nano

In questo articolo (vedi precedente) illustriamo il funzionamento dell’IC FT232H per poterlo così interfacciare alla nostra scheda FPGA DE0-Nano

L’FT232H permette di eseguire due tipi di operazione nella modalità FT245 sincrona: operazione di lettura ed operazione di scrittura.

timing

Operazione di lettura

Un’operazione di lettura può iniziare quando il chip porta il pin RXF#, che quindi andrà monitorato, a LOW. L’FPGA può portare il pin OE# a LOW per far presentare il primo byte sul bus (i pin ADBUS) dopodiché può portare il pin RD# a LOW per informare il chip dell’avvenuta lettura. Tenendo il pin RD# a LOW si possono leggere sequenzialmente più dati, o si può interrompere la lettura portando ad HIGH il segnale RD#.

Sul fronte di salita del clock (pin ACBUS5) saranno presentati i sequenzialmente gli ulteriori dati. Una volta letti tutti i dati disponibili il segnale RXF# verrà portato ad HIGH dal chip.

NB: E’ importante monitorare sia sul fronte di salita sia di discesa il segnale RXF# per poter portare ad HIGH i pin OE# ed RD# al primo fronte di salita del clock nel caso il segnale RXF# venga portato ad HIGH nel fronte di discesa precedente, come illustrato nel diagramma.

Operazione di scrittura

Un’operazione di scrittura può essere iniziata quando il pin TXE# è LOW. WR# deve essere portato a LOW quando i dati presentati sul bus sono validi. Una scrittura sequenziale può essere fatta ad ogni fronte di salita del clock mentre TXE# è ancora LOW. La FPGA deve monitorare TXE# per assicurarsi che i dati possano essere accettati. Sia TXE# che WR# devono essere LOW per far si che i dati vengano accettati.

NB: Così come nell’operazione di lettura è importante monitorare sia sul fronte di salita sia di discesa il segnale TXE# per poter portare ad HIGH il pin WR# al primo fronte di salita del clock.

Tempistiche

E’ estremamente importante rispettare le seguenti tempistiche

timing_table

Per assicurarsi che la FPGA rispetti i vincoli temporali sarà necessario impostare i vincoli tramite un file SDC (Synopsys Design Constraints) ed impostare ragionevolmente il carico capacitivo dei pin tramite Quartus.

Sotto è riportato un esempio di file SDC con in particolare i vincoli di Setup ed Hold Time

sdc

Diagramma a blocchi del sistema di LoopBack

Per illustrare meglio sia la lettura che la scrittura realizzeremo un semplice loopback, ovvero la ricezione e la ri-trasmissione di dati tramite USB 2.0.

schematic

Il clock fornito dal chip FT232H viene utilizzato anche per la logica interna, per migliorare l’aderenza alle tempistiche è introdotto preliminarmente in un PLL dove è possibile tramite sfasamento migliorare i tempi di Setup o di Hold.

Il sistema è composto da due blocchi principali: ft232h_loopback che contiene la vera logica del sistema, implementata tramite macchina a stati finiti, ed il blocco single_port_ram, una semplice memoria SRAM implementata direttamente su FPGA il cui scopo è memorizzare i dati letti durante la fase di scrittura. La memoria funge da buffer per migliorare le prestazioni del sistema ed evitare di scrivere il dato subito dopo ogni byte letto.

La dimensione del buffer è personalizzabile senza modificare il codice dei blocchi ma semplicemente cambiando il valore dei parametri associati, nell’immagine è presente un buffer di 2KB (2048 bytes) pari a 16384 bit, il 3% della memoria integrata nella FPGA della DE0-Nano.

Macchina a stati finiti

La macchina a stati finiti implementata nel blocco ft232h_loopback è molto semplice e sotto illustrata graficamente

fsm

Il processo che determina lo stato successivo, basato sullo stato corrente e sugli ingressi è il seguente:

states

Dove writeIndex rappresenta l’indirizzo della SRAM dove avverrà la lettura o la scrittura

Il processo che determina le uscite in base allo stato corrente e agli ingressi è il seguente

output

Da notare l’utilizzo dell’alta impedenza sul bus durante la lettura. Essendo il processo non dipendente dal clock il monitoraggio dei segnali nRXF ed nTXE avviene correttamente, congruamente a quanto detto precedentemente.

Memoria RAM

L’implementazione della memoria RAM è quella classica, realizzata a partire dai template predefiniti di Quartus

sram

Presenta parole di lunghezza 1 byte mentre la dimensione della memoria è impostata tramite il parametro generico ADDR_WIDTH.

L’utilizzo di risorse finale del sistema così implementato è molto ridotto e lascia spazio all’implementazione di altre funzionalità sulla scheda

res

Per quanto riguarda la parte FPGA è tutto, vedremo nel prossimo articolo come realizzare il software per scrivere e leggere dati tramite USB 2.0 ed interfacciarci quindi alla scheda DE0-Nano ad altissima velocità.

domenica 16 febbraio 2014

FPGA: Comunicazione ad alta velocità tramite USB 2.0 (prima parte)

Uno dei principali problemi in sistemi composti da FPGA e PC è stabilire una comunicazione semplice, veloce ed affidabile. Vediamo in questo articolo come aggiungere alla scheda di sviluppo DE0-Nano il supporto USB Hi-Speed (fino a 480 MBit/s teorici) per aprire nuovi scenari di sviluppo come l’acquisizione ed elaborazione di dati ad alta velocità.

pin1

La scheda di sviluppo DE0-Nano dispone di due pin header superiori da 40 pin (2x20) che permettono l’espansione della scheda.

um232

Utilizzeremo l’header GPIO-1 per collegare la scheda di sviluppo UM232H basata sull’IC FT232H di FTDI che offre una comunicazione USB 2.0 tramite un’interfaccia FIFO sincrona ad 8 bit di semplice utilizzo che offre trasferimenti fino a 40 MBytes/s. Da prove pratiche in alcuni casi, sfruttando vari buffer, si sono misurate velocità di trasferimento addirittura superiori.

ft232h

Sopra il diagramma a blocchi del chip FT232H, tra le altre funzionalità è possibile notare un buffer di 1K Bytes in ricezione e trasmissione

Lo schema del modulo di espansione è abbastanza semplice, non contiene elementi aggiuntivi e collega la scheda FPGA a quella USB 2.0 impostando tramite i collegamenti l’alimentazione del modulo UM232H in modalità self-powered, ovvero alimentata tramite la scheda DE0-Nano e non dalla porta USB.

schematic

Il consumo del modulo UM232H è molto contenuto, circa 60mA ma solamente quando collegato tramite USB al PC, rendendolo appetibile anche in applicazioni alimentate a batteria. A PC scollegato il consumo del modulo è non rilevante in quanto in stand-by grazie al pin PWRSAV#.

Sotto un’immagine del prototipo del modulo USB 2.0, realizzato tramite Toner Transfer, collegato alla scheda di sviluppo.

16022014228

Configuriamo il modulo UM232H

Una volta realizzato il modulo di espansione e collegato al PC tramite il programma FT Prog è possibile configurare la EEPROM a bordo dell’UM232H contenente le configurazioni del modulo.

ftprog

In particolar modo impostiamo nella pagina USB Config Desciptor il dispositivo come Self Powered, selezioniamo inoltre il canale come 245 FIFO ed il Driver come D2XX Direct come mostrato nelle seguenti immagini:

ftprog_fifo

ftprog_driver

Il driver Virtual COM Port seppur permetta di sostituire senza sforzo vecchie porte seriali nei software dove previste non permette di raggiungere velocità elevate. D2XX offre un’API semplice ed efficiente, disponibile sia in C/C++ sia in linguaggi come C#.

Prossimamente vedremo come realizzare il software lato PC e come programmare la FPGA per realizzare una semplice applicazione di LoopBack (es. un file inviato alla FPGA e ritrasmesso al PC) al fine di verificare il funzionamento del tutto.

Vi lascio per il momento solamente un’altra immagine..

sw

A presto