Constraints progetto FPGA

[Leonardo]

Salve a tutti,

Per realizzare una comunicazione PC-FPGA ad alta velocità tramite USB 2.0 sto utilizzando l'IC FT232H (tramite dev-board UM232H) nella modalità 245 FIFO sincrona che necessita le seguenti tempistiche:



Volevo chiedere consiglio per quanto riguarda le constraints del progetto lato FPGA, nel file SDC al momento ho inserito le seguenti istruzioni

Code: Select all

create_clock -name "FT_CLK" -period 16.67ns [get_ports {FT_CLK}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[0]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[1]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[2]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[3]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[4]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[5]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[6]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {ADBUS[7]}]
set_output_delay -add_delay -min -clock [get_clocks {FT_CLK}]  7.500ns [get_ports {nWR}]
# Automatically constrain PLL and other generated clocks
derive_pll_clocks -create_base_clocks
# Automatically calculate clock uncertainty to jitter and other effects.
derive_clock_uncertainty


Si può aggiungere (o togliere) secondo voi qualcos'altro di utile?

Grazie a tutti
Ciao

[Leonardo]

Scordavo, l'FPGA deve solamente inviare dei dati al PC e mai leggere per il momento, quindi chiedevo relativamente alla sola parte di scrittura (CLKOUT, TXE#, Data, WR#)

[deluca]

@Leonardo,
I segnali da te circostritti() sono più o meno quelli tipici che utilizziamo di solito in modalità "Synchronous Parallel FIFO Interface" e i constraints quelli riportati in tabella del pdf FT-232H. Non è che siano particolari restrizioni.

Che transfer/rate hai bisogno? e per quale scopo?

[Leonardo]

Ciao Giovanni,

Si ho riportato per comodità, condensandole, alcune informazioni dal datasheet. La modalità che utilizzo è proprio la "Synchronous Parallel FIFO Interface".

Vorrei realizzare un transfer rate di 40MByte/s per trasferire rapidamente alcuni dati generati dalla FPGA al PC. Ho già realizzato il sw di benchmark lato PC utilizzando il driver D2XX e la parte VHDL per la FPGA che per il momento semplicemente invia ripetutamente i numeri da 0 a 255 al pc.

Dai test che ho eseguito (con devboard UM232H + devboard Cyclone II EP2C5, collegamento con cavetti jumper) ho raggiunto in ricezione circa 42MByte/s, ho notato però che alcuni bit ricevuti ogni tanto (es. 1 errore al secondo) sono errati, da quello che ho potuto constatare sono sempre nelle solite posizioni (es. bit0/1 o bit4/5)

Ad esempio ottengo la sequenza ..31..16..32.. che in binario equivarrebbe ad:
00011111 31
00010000 16
00100000 32

altre volte il primo bit non cambia es. passa da ..192..194.. saltando 193
11000000 192
11000010 194

Questi problemi mi hanno fatto pensare a qualche constraints mancante nel file SDC che causa la sintesi di hardware non aderente ai timing del datasheet, per questo chiedevo consiglio per il file SDC.

Grazie come sempre
Ciao

[deluca]

Ok,
il problema potrebbe essere causato invece dal tipo di collegamento volante tra la scheda FPGA e la UM232H.
A queste frequenza entrano in gioco altri fattori legati alle interferenze di cross-talk tra le connessioni, specie se realizzate in questo modo.

[Leonardo]

Avevo provato ad impostare uno slew-rate minore su tutti i pin ma non aveva risolto il problema, il collegamento era uno degli indiziati principali.
Speravo in un problema ancora più semplice risolvibile ricompilando con constraints più restrittive ma indagherò meglio prima in quella direzione allora.

Grazie,
Ciao

[Leonardo]

Dopo analisi più approfondite ho riscontrato che esattamente ogni 510 bit si verifica un errore di trasmissione, valore che sale vertiginosamente eliminando le constraints (e senza fast output register), la situazione in tal caso peggiora di circa 20 volte (in media).

Ragione che mi fa pensare a problemi con le constraints.. una qualche problematica nella connessione avrebbe penso un comportamento più random

Ecco parte dei log che ho generato:
- nella prima colonna il numero del byte ricevuto contenente l'errore
- nella seconda il numero effettivo ricevuto
- nella terza la sua rappresentazione binaria (per comodità)
- quarta colonna il valore precedentemente ricevuto (nella prima riga bisognava quindi ricevere 13 invece che 14)
- quinta colonna la sua rappresentazione binaria

#byte valore ricevuto valore precedente
17 14 00001110 12 00001100
527 13 00001101 11 00001011
1037 12 00001100 10 00001010
1547 11 00001011 9 00001001
2057 10 00001010 8 00001000
2567 9 00001001 7 00000111
3077 8 00001000 6 00000110

Eliminando le constraints invece

#byte valore ricevuto valore precedente
16 29 00011101 27 00011011
19 33 00100001 31 00011111
50 65 01000001 63 00111111
81 97 01100001 95 01011111
112 129 10000001 127 01111111
143 161 10100001 159 10011111
174 193 11000001 191 10111111

Sembra non esserci una regolarità così forte tra il numero di byte passati da un'errore all'altro

Il pseudocodice del sw lato pc (semplificato)

Code: Select all

OpenBySerialNumber("FTXE2X2D");
SetBitMode(0xFF, FTD2XX_NET.FTDI.FT_BIT_MODES.FT_BIT_MODE_RESET);
Thread.Sleep(10);
SetBitMode(0xFF, FTD2XX_NET.FTDI.FT_BIT_MODES.FT_BIT_MODE_SYNC_FIFO);           
Purge(FTD2XX_NET.FTDI.FT_PURGE.FT_PURGE_RX | FTD2XX_NET.FTDI.FT_PURGE.FT_PURGE_TX)
--Ciclo dove leggo 1kbyte (dimensione buffer ft232h) alla volta
  Read(dataBuffer, 1024, ref numBytesRead);   
--Fine Ciclo
Close();


Allego progetto Quartus (con constraints commentate) nel caso potesse servire
Ne ho provate veramente tante..

[Leonardo]

Il problema sembra essere più complicato del previsto..
- muovendo il cavo il tasso di errore aumenta/diminuisce sempre con errori dopo N letture in molti casi
- leggendo 1 byte alla volta lato sw non si riscontrano mai errori, la velocità di lettura è però intorno ai 0.2MB/s.. troppo lenta
- non dispongo di attrezzatura al momento per fare Signal Integrity su frequenze così elevate

Mettendo assieme tutte le considerazioni,
concludo etichettando con molta probabilità il problema come Signal-Integrity(SI), come aveva predetto Giovanni

*Alcuni riferimenti che ho consultato ma che non hanno risolto il problema:
http://www.ovro.caltech.edu/~dwh/correl ... f/ftdi.pdf
http://www.alteraforum.com/forum/showthread.php?t=36452
http://www.alteraforum.com/forum/showthread.php?t=42877

[Leonardo]

Ciao a tutti,

Vi aggiorno sulla situazione. Per tagliare la testa al toro sul collegamento tramite cavi jumper ho realizzato un piccolo adattatore che si inserisce direttamente sulla dev-board della FPGA: https://imageshack.com/i/ma6t3xj purtroppo non ho potuto realizzare un PCB di qualità industriale ma mi sono dovuto accontentare della millefori.

Sottolineo che l'adattatore non preclude quindi problematiche di Signal Integrity ma ne riduce leggermente l'entità.

Ho fatto prove modificando la corrente in uscita e lo slew rate dei pin del modulo FDTI tramite FT_Prog (l'utility di FDTI per configurare la EEPROM del chip) ma il risultato non è cambiato.

La perdita di dati è costante, quantificata nello 0,002%. Il buffer nella modalità FIFO è 512 byte (e non 1KB), una perdita di un byte ogni 510 byte può quindi rilevare una relazione tra buffer ed errori.

Il diagramma del timing del chip non è molto esplicito, sembra che:
- TXE# passi a HIGH sul fronte di discesa del clock

Non sono inoltre indicati i tempi di salita e discesa

Seguiranno immagini della simulazione Modelism (a livello di gate)..

[Leonardo]

L'arcano è finalmente svelato a quanto sembra:



Quando il buffer è pieno nTXE viene portato HIGH dall' IC quindi sembra spiegarsi la relazione tra la frequenza dell'errore e la capacità del buffer.

Renderò disponibile il codice funzionante non appena avrò corretto e testato approfonditamente il nuovo codice.

Nota: Nel file SDC mi sembra che max è invertito con min in quanto:
max = setup time
min = hold time

Quindi il file SDC dovrebbe diventare:

Code: Select all

create_clock -name "FT_CLK" -period 16.67ns [get_ports {FT_CLK}]

set_input_delay -clock { FT_CLK } -min 9ns nTXE
set_input_delay -clock { FT_CLK } -max 0ns nTXE

set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[0]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[1]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[2]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[3]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[4]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[5]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[6]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {ADBUS[7]}]
set_output_delay -max -clock "FT_CLK"  7.500ns [get_ports {nWR}]

set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[0]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[1]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[2]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[3]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[4]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[5]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[6]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {ADBUS[7]}]
set_output_delay -min -clock "FT_CLK"  0ns [get_ports {nWR}]


Grazie a tutti per il supporto che mi avete dato (anche morale)

[Leonardo]

Purtroppo il problema non è ancora stato svelato

Rivedendo il diagramma quando nTXE è LOW ed nWR va LOW al fronte di salita il dato letto è 35 e non 36 (per convincersene basta confrontarlo meglio col diagramma dei tempi)

Inizio a pensare che ci siano problemi lato driver da parte di FDTI:

- ho provato sia il wrapper .NET con C# che la libreria DLL con C++, in molti casi risultati diversi (error rate diversi) a quello che dovrebbe essere codice equivalente, ripetendo con la solita versione l'esperimento nelle solite condizioni si ottengono invece risultati identici.

- Su Windows 7 / XP la funzione Purge del wrapper .NET blocca completamente il programma che non si riesce a chiudere neppure da Task Manager.

- Il supporto tecnico di FDTI non risponde (ho posto domande sulla libreria D2XX)

- Le release notes http://www.ftdichip.com/Drivers/CDM/CDM%202%2008%2030%20Release%20Info%20for%208.1.rtf del driver contengono in passato issue come "Fixed synchronisation issue that could lead to data loss", utilizzo però l'ultima versione del driver che dovrebbe essere stata corretta.

- Cambiando la dimensione del buffer di lettura (lato sw) a parità di forme d'onde uscenti dalla FPGA non si ottengono errori solamente leggendo 1 byte per volta (solo con il wrapper .NET, con la libreria nativa si ottengono errori):



Ho fatto diverse prove un po di fretta nei ritagli di tempo ma l'esperienza avuta con questo IC fin'ora è tutt'altro che positiva.

@Giovanni: Avete usato senza problemi proprio l'IC FT232H o l'FT2232H nella modalità 245 sincrona?

[Leonardo]

Voglio ringraziare in primis il supporto tecnico FTDI che mi ha risposto e risolto il problema.

I think you are not de-asserting the WR# until the cycle after TxE has been de-asserted by the chip.I think it’s not stopping after 510 bytes and is sending one more. The chip will sometimes have a short pause after 510 bytes (since you get 510 plus 2 status bytes per USB packet) and you would lose the 511th byte.

In pratica il segnale TxE può essere portato LOW dall'IC sia sul fronte di salita sia sul fronte di discesa, aspetto che non mi era chiaro dal datasheet. La FPGA controllando sul solo fronte di salita il segnale TxE e portando sul successivo fronte a LOW il segnale WR# aveva un comportamento ritardato che induceva errori sui dati.

La soluzione funzionante è quindi la seguente:

Code: Select all

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ft232h_tx is
   port
   (      
      FT_CLK   : in std_logic;                     -- 60 MHz FT232H clock
      nTXE      : in std_logic;                     -- Can TX
      nRXF      : in std_logic;                     -- Can RX
      nRD      : out std_logic;                     -- Read
      nSIWU      : out std_logic;                     -- Send Immediate / WakeUp
      nOE      : out std_logic;                     -- Output enable
      nWR      : buffer std_logic;                  -- FIFO Buffer Write Enable
      ADBUS      : out std_logic_vector(7 downto 0)   -- Bidirectional FIFO data               
   );
end entity;

architecture rtl of ft232h_tx is
   signal counter : unsigned (7 downto 0) := "00000000";
   signal state : std_logic := '0';
begin
   
   -- don't read
   nOE <= '1';
   nSIWU <= '1';
   nRD <= '1';
   
   process(FT_CLK, nTXE)      
   begin   
      if (rising_edge(FT_CLK)) then
         if(nTXE = '0') then
            if(state = '1') then
               --nWR <= '0';
               ADBUS <= std_logic_vector(counter);
               counter <= counter + 1;
            end if;
            state <= '1';
         else
            --nWR <= '1';
            state <= '0';                     
         end if;
      end if;      
   end process;

   nWR <= '1' when nTXE = '1' else
          '0' when (nTXE ='0' and state = '1');
   
end rtl;


In cui il segnale nWR viene portato ad 1 subito dopo che il segnale nTXE viene portato ad 1 a differenza del codice precedente.

Ringrazio anche quanti intervenuti nel thread e Giovanni che mi ha dato assistenza per chat.

[deluca]

@Leonardo,
ottimo lavoro, direi!!
aver svelato la risoluzione del problema potrà essere di aiuto ai possibili fruitori del forum
e a quelli che si imbatteranno in applicazioni simili.

grazie mille.

[legacy]

Obiettivo finale ?

[Leonardo]

Salve a tutti,
Visto che se ne è parlato, a chi fosse interessato alla comunicazione FPGA - PC tramite USB 2.0 segnalo i miei articoli dove ho spiegato come implementarla:

Prima parte (introduzione e configurazione UM232H)
http://electro-logic.blogspot.it/2014/02/fpga-comunicazione-ad-alta-velocita.html

Seconda parte (progetto FPGA)
http://electro-logic.blogspot.it/2014/03/fpga-comunicazione-ad-alta-velocita.html

Terza parte (Software)
http://electro-logic.blogspot.it/2014/03/fpga-comunicazione-ad-alta-velocita_16.html

Download progetto
http://electro-logic.blogspot.it/2014/03/fpga-comunicazione-ad-alta-velocita_3163.html

[legacy]

si, ma per farci che cosa ?

[Leonardo]

Le applicazioni sono molteplici, per esempio acquisizione dati ad alta velocità