delucagiovanni forum

Salve a tutti, mi sono appena registrato!
Ho a disposizione una board basata su una stratix iv, sono abbastanza pratico di FPGA, ma per ora ho sempre fatto signal processing, ora vorrei buttarmi su NIOS, ma ne so veramente poco.
La mia idea sarebbe quella di crearmi una interfaccia I/O basata su eternet (come base UDP, per il TCP magari in futuro ) per i dati in ingresso\uscita alla parte di signal processing. Fino ad ora ho utilizzato un chip ftdi usb, ma volevo cercare di avere una interfaccia più generica e performante (niente PCIexpress per esempio).

Ho letto un po' di esempi e tutorial ma ho un po' di confusione quindi mi sono deciso a rivolgermi a qualche forum con qualche domanda diretta, ed eccomi qui (spero di essere nel posto giusto!)

Innanzi tutto vorrei capire se ho capito (scusate il gioco di parole):
in generale gli esempi che ho trovato che sviluppano interfacce ETH tramite l'uniphy controller utilizzano NIOS + un mini SO e quindi le richieste di risorse non sono proprio basse, parlo principalmente di onchip memory per storare il programma.
Probabilmente è possibile anche gestire il tutto senza SO, ma vorrei mantenere questa liena.
Visto che non voglio occupare risorse sull'FPGA in questo modo ho indagato sulla possibilità di utilizzare la DDR RAM esterna all'FPGA (la mia board monta una dim DDR3 da 1GB).
Da quello che ho capito dovrebbe essere possibile per NIOS eseguire l'intero programma dalla memoria esterna, avendo quindi come unica ram utilizzata la sua cache,
è così, e basta il boot loader standard?

Per ora sto cercando di adattare degli esempi che ho trovato ma con poco successo, avete qualche tutorial simile a quello che mi serve da consigliarmi?

Come primo post mi sembra sufficente
Grazie in anticipo

Salve Marco e benvenuto al forum,
Non ho mai usato NIOS intensamente, ho proprio solamente dato un'occhiatina in passato ma mi sembra che la direzione sulle nuove dev-board è sui core ARM o sbaglio?
Tornando al quesito, che prestazioni di I/O cerchi?

Ciao
Leonardo

PS: Nel manuale della board DE0-Nano se non erro c'è un tutorial su NIOS interessante
https://www.terasic.com.tw/cgi-bin/page/archive_download.pl?Language=English&No=593&FID=75023fa36c9bf8639384f942e65a46f3

Ciao Leonardo,

so che il trend è quello ARM, ma per iniziare spero (o meglio speravo ) che NIOS fosse un po' più semplice.
L'idea è quella di raggiungere i 500Mbit (250 in 250 out).
Per ora ho due flussi in parallelo:
il primo prevede NIOS + onchip + TSE con il quale vorrei iniziare i primi test di trasmissione
il secondo è più vicino all'architettura finale quindi ha NIOS + TSE + flash + DDR3.

Nel caso 1) NIOS risponde, riesco a far girare l'hello world base e quello con uCOS ma non il simple socket server perchè ci sono delle differenze nell'architettura. Quindi sto cercando (senza successo) di partire dall'esempio uCOS e aggiungerci la parte software di gestione socket. Non riesco però a "spostare" le librerie da "simple socket" infatti una volta spostati i file nella cartella del progetto uCOS questi non vengono comunque visti da Eclipse e gli "include" non vengono risolti.

nel caso 2) ho 2 problemi fondamentali il primo è che una volta buildato tutto il sistema Eclipse non passa il check su alcuni indirizzi:
"Using cable "USB-Blaster [USB-2]", device 1, instance 0x00
Processor is already paused
Reading System ID at address 0x480044D8:
ID value verified
Timestamp value was not verified: value was not specified
Initializing CPU cache (if present)
OK

Downloading 20000020 ( 0%)
Downloading 20008098 (79%)
Downloading 48001000 (99%)
Downloaded 33KB in 0.5s (66.0KB/s)

Verifying 20000020 ( 0%)
Verify failed between address 0x20000020 and 0x200065E7
Leaving target processor paused"

che sono proprio quelli corrispondenti alla DDR3.
L'altro grosso problema in questo flusso è che Quartus non riesce a chiudere i timing e ho slack negativi come se piovesse e onestamente non so bene come risolverli dato che è tutto hardware auto generato (forse dovrei inserire un bridge sul bus verso la DDR).

Mi serve decisamente un tutorial (o qualche pia persona) che spieghi un po' meglio i passi perchè c'è qualcosa che mi sta sfuggendo.

Ciao

la parte DDR non e' che va da wizard e via, ci devi mettere tu mano ed e' nota per essere una rogna, e pure la parte al lato firmware che inizializza il DDR controller. Boh, vuoi farti proprio male

Eclipse e' noto per dare molto fastidioso con i metadata, spesso si risolve con un purge totale e brutale, clean everything and make everything again, a volte pero' si corrompe il metadata di progetto e li … io faccio prima a rifare il progetto ex novo.

in effetti pensavo fosse meno problematico, ma altrimenti come faccio per consumarmi meno ram su fpga possibile?

io non avrei messo un kernel su fpga, p.e., e' un casino bestia da debuggare gia' sui micro, e costa pure uno sproposito cosi', sulle fpga … e' una scala di due zeri + complesso/costoso.

detto ciò io avrei messo da parte nios, mi sarei preso una schedina arm o dsp a cui avrei affiancato la fpga modi acceleratrice, ovvero periferica di cooprocesso, nel mio caso cooprocessori crittografici, mi danno una mano nei vari calcoli di anello, semplici per concetto (si fa per dire) molto pesanti da fare per una CPU, sopratutto se gli anelli sono a 128bit e la CPU a 32.

nel tuo caso puoi pure buttarti su schedine arm con built-in lan, con spi ad alta velocità e/o porti paralleli, entrambi per agganciare l'fpga che nel caso si riduce pure come onere.

Fai prima, e ti fai meno male.



Senno, incomincia a mettere a posto il DDR, e auguri !

Come dice legacy, hai ancora tempo per cambiare idea....
Dopo innumerevoli tentativi ho abbandonato l'approccio NIOS per migrare su Cortex-M3/4 + FPGA Altera.
Secondo me, l'accoppiata vincente e ti svincoli dai vincoli

Se necessiti di un'interfaccia generica ampiamente disponibile sui PC potresti indirizzarti su qualche dev-board con USB 3.0 per avere velocità elevate di I/O, con USB 2.0 servirebbero due canali per raggiungere i 500 Mbit

Ciao

Ciao a tutti e grazie per le risposte
Quello che dite è sicuramente vero (cioè che un SO su FPGA è una rogna e che usare la ram esterna non è così semplice), tanto è vero che fino ad ora l'approccio è sempre stato:
FPGA per il processing + USB + PC (per il controllo e I/O dati).
Ora ho necessità di aumentare il throughput quindi la USB2 non va più bene ed inoltre volevo potermi interfacciare verso apparati di terze parti (non necessariamente dei PC o dei PC per i quali sia disponibile il driver USB) in maniera più generica, quindi una bella ethernet mi è sembrata una interfaccia adatta.
Se riuscissi a far funzionare NIOS avendo accesso alle ampie risorse esterne all'FPGA potrei anche pensare di spostare l'intera parte di controllo dal PC a NIOS con il vantaggio di avere un apparato molto compatto. Attualmente senza l'ausilio della RAM sono riuscito a far girare il kernel tutto sulla onchip ma in questo modo ho "bruciato" il 30% della RAM dell'FPGA e il 9% della parte logica (anche se internamente ho anche il core che mi gestisce l'FTDI e parecchi registri di configurazione).
Attualmente sono alla ricerca di informazioni su come utilizzare i 2MB di SSRAM, sempre esterni, che dovrebbero essere più facili da utilizzare (mi sembra di aver capito che basta il tristate controller) per poterci spostare la memoria dati e programma, già questo mi farebbe riguadagnare gran parte dei block ram usati.
Certo, lo so che partendo da zero è un po' difficile, ma altrimenti non c'è divertimento no?

Vi ringrazio comunque dei consigli e se vi fa piacere ogni aiuto è chiaramente ben accetto

Gianmarco

Leggo che vuoi spostare la parte di controllo sotto NIOS e bah … io non ho capito a cosa ti serva l'fpga oltre al SoC, ma nel caso, proprio riguardo al SoC, e proprio al riguardo "Application on Chip", io mi prenderei un sistemino embedded-linux e/o altro cmq con built-in lan a 1000Mbit/sec, ce ne sono in giro un po' ultimamente, ti costa pure di meno ed e' altrettanto compatto, oltre al fatto che ti offre meccanismi kernel ed userspace per la programmazione concorrente e per i socket di rete.

tu esisti o sei fuggito ? news ?

io sto stra-maledicendo i SoC HDL, non perche' li abbia scelti, me li hanno rifilati
ed e' una rogna infinita sopratutto nel porting tra tecnologie diverse, p.e. from Altera to Xilinx
ma anche tra due famiglie diverse Xilinx vengono fuori magagne infinite!

Ahah, si si, il porting tra Xilinx e Altera è sempre una rogna, anche per quanto riguarda delle semplici macro.
Nella mia personalissima esperienza mi sono trovato meglio con Altera (più che altro per Quartus), ma purtroppo mi capita di dover passare da una all'altra e ogni volta mi trovo a "divertirmi" anche con i bachi di ISE.

eh, i bachi di ISE, tu quali hai collezionato ?

io tra i + simpatici mi sono pure cuccato nella v10.1 il bellissimo difetto per il quale se editi un file in condizioni particolari con editor HDL esterno e ti si corrompono i medata ti salta tutto il progetto, proprio ISE fa pialla e tabula rasa, e meno male che almeno i sorgenti RTL e le constraints sono text e li lascia inviolati

fa paura questo baco, pero' non ho voglia di parcheggiare 20Gbyte di fuffa sul disco fisso giusto per passare da ISE v10.1 (meno di 8Gbyte) ad ISE v14, sempre poi che la faccenda sia stata risolta

A pro po di SoC, un altra rognaccia che dipende dalla tecnologia e' la bram. Cavolo ad un SoC serve la bram, non ne puoi fare a meno e sarebbe stupido implementare una CPU in fpga per poi ripiegare totalmente su ram e flash esterna (almeno per quanto riguarda le risorse minime di early bootstrap), quindi cosa fai ? Non la usi ? Ecco, ci si scontra con il fattaccio che nel descrivere una ram/rom in HDL in modo generico poi il motore di sintesi non e' detto che la sappia sintetizzare nel modo migliore, ovvero sfruttando la vera bram fisica piuttosto che una accozzaglia di celle. Quindi per aiutare il motore di sintesi e' buona norma forzare la faccenda scendendo ai dettagli + intimi della propria fpga per quanto riguarda la bram. Tutto ottimo, eccetto il fatto che facendo cosi' poi i file non sono portabili, nemmeno all'interno dello stesso costruttore: Spartan3 non ha lo stesso modello di bram della spartan6, cosi' come la spartan2 non lo e' verso spartan3. E figuriamoci verso o da Altera


Morale della faccenda, per 32Kbyte di ram dentro a sto cavolo di SoC vanno via 4 ore di imprecazioni ed almeno 2 giorni per riscrivere rivalidare il tool di turno per infilare il contenuto di un elf nel codice HDL. Altera ha un tool apposito, Xilinx NI (ed e' più NO che SI, anche perche' e' molto scomodo e complicato)