codice VHDL

[florius]

Quando scrivi: <<ma per quanto riguarda la simulazione, si apre un capitolo a parte, non mi riferisco al testbench che è abbastanza intuitivo ma, allo stesso tempo, molto limitato. Parlo di simulazioni fatte con tool dedicati (ad esempio Modelsim) e per i quali devi imparare un ulteriore modo di scrivere (se ci fai caso, nel language template, c'è una cartella a parte per la simulazione).>> che intendi per simulazione?
non è lo stesso che dire testbench? cioè scrivere un codice che "simula" i segnali d'ingresso?!
ah se potessi spiegarmi di persona!!
ciao

 

[florius]

su un manuale leggo:
begin
U1: xor3
port map (
O=> S,
i1=> a,
i0=> b);
......
end structural_view;
Cosa vuol dire l'operatore =>?
P.S.spero di nn romperti! ma tu sei la mia salvezza!!!
ciao e sempre grazie

 

[Ponente]

La notizia è veramente stupenda ma, temo che il corso venga tenuto in lingua inglese e purtroppo lo capisco poco!

Vai tranquillo, tanto sicuramente il guru che ci sarà sarà un americano e non sarai l'unico a non capire quello che dice, ma l'importante è quello che fa!

Il corso che facesti tu quando durò?

Io feci un full immersion di 5 giorni dove non feci di più di quanto trovi su un qualsiasi corso su web, ma la grande differenza è che avevo un interlocutore in gamba che mi chiarì tutti i dubbi

P.S. Da alcuni manuali VHDL leggo:
-Solo un limitato sottoinsieme del VHDL è sintetizzabile; è possibile avere descrizioni VHDL sintetizzabili, ma non simulabili; è possibile avere descrizioni VHDL sia sintetizzabili che simulabili, ma i cui componenti pre e post-sintesi sono differenti-
perchè questo? che vuol dire tutto ciò?

è una frase che ho trovato in molti libri, provo a dargli una spiegazione...


Solo un limitato sottoinsieme del VHDL è sintetizzabile
!Vero: il VHDL è un linguaggio descrittivo, ma il suo risultato è un hardware (silicio!) per cui esiste sicuramente qualche costrutto che dal punto di vista della sintassi è corretto, ma in realtà non è realizzabile fisicamente...


è possibile avere descrizioni VHDL sintetizzabili, ma non simulabili;
Probabilmente parla dell'utilizzo delle variabili al posto dei segnali (cosa che ti sconsiglio vivamente). Senza scendere nel dettaglio ti dico solo che le variabili danno luogo nel silicio a costrutti che si comportanto in modo asincrono (dunque devi stare molto attento nell'utilizzo) e il simulatore non ti permette di visualizzarle se non le associ a dei segnali fisici.


VHDL sia sintetizzabili che simulabili, ma i cui componenti pre e post-sintesi sono differenti
Non riesco ad immaginare un componente pre-sintesi, ma ho due ipotesi interpretative:

la simulazione differisce dall'oggetto fisico per via delle librerie differenti-> può essere vero perchè il simulatore di solito non usa le stesse librerie del sintetizzatore (se non altro perché le sue sono di simulazione e quelle del sintetizzatore descrivono oggetti fisici).

la simulazione differisce dall'oggetto fisico per via di costrutti asincroni che danno luogo a violazioni di timing -> frequentissimo quando i costrutti asincroni hanno latenze troppo elevate rispetto al clock (ad esempio macchine a stati con molti stati, contatori molto grandi ecc..) o quando il clock non è pulito o proviene da net ad alto skew.
In questi casi esistono poche semplici regolette da tenere sempre presenti:
- il clock è sacro, e deve essere mantenuto tale
- i costrutti devono essere semplici
- bisogna usare i pll e i buffer
- bisogna leggersi tutti i warning che il compilatore restituisce

Buon lavoro

 

[florius]

Caro ponente,
con il vhdl arrivano sempre dei problemi: non capisco dov'è lo sbaglio nel codice che vedi in figura

http://img410.imageshack.us/img410/2031/immagineap.png

ho provato a scriverlo con una leggera modifica e sempre un problema, anche se diverso:

http://img30.imageshack.us/img30/7262/immagine1ru.png

ATT. l'immagine http://img30.imageshack.us/img30/7262/immagine1ru.png nn è quella che volevo mandarti, quella corretta è la stessa con la differenza che when others nn è messo come commento, ho premuto involontariamente -- prima di copiare l'immagine.
come si risolve il problema? a me sembra tutto corretto!
ciao e a risentirci presto

 

[Ponente]

Prova a scrivere '<=' invece che '=<' nel when others (che deve esserci sempre, anche quando copri tutti i casi) e vedrai che la sintassi sarà a posto...


L'operatore '<=' e l'operatore '=>' sono operatori di assegnazione e non devono essere confusi con gli equivalenti delle espressioni booleane (il contesto discrimina le situazioni).
Per quanto riguarda la scelta di '<=' piuttosto che '=>' deve essere fatta in base alla locazione dell'operatore, guardando qualche esempio ti dovresti poter orientare bene, al più fai riferimento al language template, ma vedo che già le prime linee di codice cominciano a prendere forma quasi correttamente...

 

[Ponente]

Quando scrivi: <<ma per quanto riguarda la simulazione, si apre un capitolo a parte, non mi riferisco al testbench che è abbastanza intuitivo ma, allo stesso tempo, molto limitato. Parlo di simulazioni fatte con tool dedicati (ad esempio Modelsim) e per i quali devi imparare un ulteriore modo di scrivere (se ci fai caso, nel language template, c'è una cartella a parte per la simulazione).>> che intendi per simulazione?
non è lo stesso che dire testbench? cioè scrivere un codice che "simula" i segnali d'ingresso?!
ah se potessi spiegarmi di persona!!
ciao

Il testbench non è altro che un wizard, dopo aver costruito un disegno con gli stimoli e averlo salvato, se vai nella cartella di lavoro, troverai un file con lo stesso nome del testbench, ma con estensione .vhw
Se lo apri vedrai che è un VHDL e non è altro che la descrizione degli stimoli che hai disegnato. Tool come Modelsim capiscono solo questo tipo di file (dunque sono banditi anche file di tipo schematico, pallogrammi ecc...)

Ma quando scrivi un file di stimoli in VHDL puoi fare veramente di tutto: per esempio puoi modellizzare dei dispositivi che colloquiano con la tua FPGA, ossia fornire al tuo progetto degli stimoli che sono conseguenza di segnali che hai inviato, oppure puoi simulare n FPGA, anche di case diverse, che parlano fra loro su di un bus dando in pasto al simulatore gli n progetti sviluppati con m tool differenti, oppure puoi prendere dall'harddisk un file di dati sniffati dal bus e fornirlo come stimoli al tuo progetto... e così via

Queste cose verranno naturali in base alle esigenze del progetto su cui lavori, per cui non ti preoccupare, nè c'è bisogno che ti faccia scuola io, non ne avrei il tempo.

Il VHDL è tutto sommato semplice, devi solo capire il concetto che c'è alla base:
tutto quello che scrivi si traduce in hardware, ogni riga di codice è silicio che consumi
Pertanto dimentica tutti i linguaggi di programmazione che conosci perchè non c'entrano niente con quello che ti accingi a fare. Per esempio, se dai uno sguardo più approfondito al codice che ti ho manipolato, noterai che i due processi che avevi scritto li ho messi uno accanto all'altro nello stesso processo. Se lo guardi con gli occhi di un softwarista i costrutti li vedrai come se fossero in sequenza, in realtà come te li ho scritti io sono svincolati fra di loro e agiscono in parallelo, così come avrebbero fatto se fossero stati scritti in due processi separati. Non c'è nulla di sbagliato nel primo modo di scrivere, ma si vede l'impronta di una programmazione multitasking tipica del software... ebbene nel VHDL ogni riga di codice di ogni file del tuo progetto è in multitasking con tutte le altre di tutti gli altri file, la sequenzialità c'è solo quando usi dei costrutti dedicati.

Non appena avrai assimilato queste quattro cose che ti ho scritto... ti mancherà solo un pò di esperienza sul campo e poi andrai come un treno...

A presto

 

[florius]

come ti dicevo sono stato al Workshop dell'ALTERA a Pomezia. Il seminario era mirato a gente già consolidata nel campo dell'elettronica avanzata, quindi ho avuto difficoltà a seguirlo anche per il fatto che la discussione è avvenuta interamente in lingua inglese. Si è parlato dei vari problemi pratici che si riscontrano nella simulazione della FPGA, come lo Jitter, problemi di interfacce veloci, problemi di alimentazione. Nel descrivere tali problemi e la loro soluzione, si è approfittato a parlare dei migliori strumenti da laboratorio oggi disponibili sul mercato da parte dei suoi partnership ( Linear Technology e Tektronix) .
E' stato mostrato l'oscilloscopio della Tektronix di memorizzazione digitale in grado di campionare ad una frequenza di 2 GHz su 4 canali contemporaneamente (formidabile!), per problemi di interfacce veloci la Linear Technology ha parlato, come soluzione del problema, dell'alimentatore di tipo Switching (Switchmode Controller Regulators) mostrando dei piccoli "chips" poco + grandi di 1 cm x 1 cm che assolvono a questo compito, riuscendo, distribuendo in modo opportuno i condensatori interni (prediligendo quelli ceramici a quelli elettrolitici), a lavorare con correnti fino a 14 A con una ben distribuita emissione termica sull'intero componente curando anche la schermatura delle induttanze.
Si è fatta una piccola prova diretta sulla FPGA serie Stratix IV GX col software Signal Integrity Board control GUI e successivamente col tool di sintetizzazione e simulazione Quartas II.

 

[Ponente]

Magnifico! anche se ti sarà sembrato troppo, hai sicuramente ampliato le tue vedute, hai visto un altro tool , hai visto un'altra tecnologia, hai conosciuto persone che hanno esperienza, scambiato idee e opinioni, sei entrato in contatto con i FAE Altera e di altre case, hai messo fisicamente le mani su un pezzo di ferro ed hai intuito che il mondo delle FPGA non si limita solo al VHDL, ma ha tante problematiche che NON vanno trascurate... soprattutto se un giorno il progetto della scheda con l'FPGA lo farai tu

 

[florius]

sto continuando a studiare il VHDL e la tecnologia delle FPGA, mi accorgo che nn vado così spedito come vorrei, probabilmente ciò è dovuto allo studio autodidattico di una materia per me nuova e soprattutto vasta.
Volevo chederti una spiegazione:
leggo su uno dei tanti file sul VHDL su web la seguente frase - Portabilità: caratteristica di un programma di poter essere eseguito su un computer di tipo diverso- questo significa che, per esempio, il programma è eseguibile su un computer di marca XX e nn su un computer di marca YY, e magari è eseguibile su un modello della marca XX e nn su un altro modello della stessa marca? il programma a basso livello tiene conto della circuteria della CPU, delle porte logiche esistenti fisicamente nel processore? in caso affermativo, ciò è dovuto al fatto che una eq.ne logica può essere "eseguita" con una combinazione particolare di determinate porte logiche a disposizione?
grazie e cordiali saluti

 

[Ponente]

'Portabilità' e/o 'riuso' sono parole che vanno molto di moda oggi: quando vuoi vendere bene un tuo prodotto software dici che è portabile su altre macchine, se vuoi fare bella figura col tuo capo puoi dire che il codice che stai scrivendo lo puoi riutilizzare per altre applicazioni simili... in soldoni significa che il lavoro che stai facendo oggi ti dà un vantaggio per un altro lavoro che farai domani, oppure che chi si compra il tuo software continuerà ad utilizzarlo anche se sostituisce la macchina sul quale gira e senza doverti interpellare.
Tutto questo è vero solo in parte, se parliamo di software e si utilizza uno standard ben definito (per esempio ANSI C, Java, PHP...) ti dico che è vero al 99%, previa ricompilazione o reinterpretazione del codice. Ma se parliamo di altre cose...
Per esempio avrai senz'altro provato ad utilizzare browser diversi da explorer, e ti sarai senz'altro accorto che alcuni siti web non vengono visualizzati nello stesso identico modo dai vari browser.
Se parliamo di VHDL si può dire che, finchè ti limiti ad utilizzare lo standard e non specifichi funzioni di libreria proprie del componente sul quale calerai il progetto, la compatibilità è quasi totale. Ma è chiaro che se utilizzi dispositivi specifici (per esempio il transceiver Altera XYZ con tutte le sue impostazioni) nel momento in cui tenterai di trasportare il tuo progetto su un altro componente, se sarai fortunato avrai un porting automatico fatto dal tool (di solito succede quando il tool riconosce entrambi i dispositivi, per esempio perchè sono entrambi Altera, e c'è una compatibilità), ma comunque la garanzia della piena compatibilità non te la da nessuno, la maggior parte delle volte il tool ti dirà che non conosce questo tipo di dispositivo e non completerà il mapping.
In questi casi devi metterti a studiare i datasheet dei dispositivi di entrambi i componenti e sostituire a mano il dispositivo in questione tentando di raggiungere la maggior compatibilità possibile a livello funzionale.
In ogni caso una simulazione del progetto finale è sempre bene farla.

Se invece vuoi metterti a fare codice VHDL riutilizzabile.... sappi che è come una coperta troppo corta: se vuoi prestazioni molto spinte devi 'cucire' il codice sull'applicazione come un sarto, e questo la rende non portabile, se vuoi fare codice portabile dovrai cominciare a scrivere processi e funzioni con tanti parametri in modo da renderle il più generiche possibile, ma così facendo pagherai la portabilità con l'efficienza in termini di silicio e velocità, oltre che in termini di complicazione del codice e di leggibilità.

Come avrai intuito io propendo per la prima ipotesi... per me i dispositivi sono sempre troppo piccoli e troppo lenti! Ma fare un porting di una funzione o di un intero progetto è un esercizio che fa senz'altro bene alla mente del progettista perchè lo abitua a pensare in grande, e scrivere funzioni e procedure pensando alla portabilità è senz'altro una buona metodologia. Ti consiglio comunque di non complicarti la vita adesso che stai imparando la materia, le funzioni portabili avrai tempo e modo di scriverle quando avrai maturato un pò di esperienza in più.

 

[florius]

Caro Ponente,
il mio datore di lavoro mi ha mandato il codice di VHDL da sintetizzare sulla FPGA e devo studiarmelo. Tu sai dirmi qualcosa sulla memoria FIFO (credo che sia una memoria dinamica)? in pratica parte del progetto riguarda una memoria FIFO dove vengono immagazzinati i dati provenienti da un sensore e poi vengono letti ed analizzati da un altro corpo.
Volevo sapere quello che c'è da sapere su queste memorie e, magari, qual'è il codice in VHDL che le rappresenta, che le descrive.
Ciao e a presto

 

[Ponente]

Memorie FIFO

FIFO sta per First In First Out, ossia il dato che entra per primo esce per primo. Sono usatissime in hardware perchè sostanzialmente servono a passare da un dominio di clock ad un altro. Supponiamo per esempio che stai ricevendo i dati da un sensore che trasmette a 100 MHz e la tua FPGA lavora a 100MHz, sicuramente il clock della tua FPGA sarà asincrono rispetto a quello del sensore e quindi dovrai necessariamente usare una FIFO che raccoglie i dati del sensore lavorando sul clock del sensore e consegna i dati alla sezione di elaborazione col clock della sezione di elaborazione. Ma così facendo non hai risolto il problema: supponiamo anche che il clock della FPGA è ideale e che quei 100MHz sono precisi fino all'hertz, sicuramente i 100MHz del sensore saranno diversi non soltanto in fase ma anche in frequenza (per esempio 100,000001 MHz). Quell'hertz in più che ha il sensore rispetto alla tua FPGA sarà sufficiente, dopo un pò, a saturarti la FIFO perchè non riuscirai a svuotarla alla stessa velocità con cui si riempie. Allora dovrai usare per la tua FPGA una frequenza più alta stando però attento che, in questo modo, la tua FIFO sarà spesso vuota. Per gestire il tutto dovrai quindi tenere sotto controllo le flag di stato della FIFO che normalmente sono : fifo piena, fifo vuota, fifo quasi piena, fifo quasi vuota, fifo mezza piena ecc...
Quali flag controllare dipende dalle tue scelte progettuali, per esempio una politica possibile potrebbe essere: aspetta che la fifo sia mezza piena, poi comincia a svuotarla finchè non è quasi vuota e infine ripeti il ciclo.
In questo modo avrai un funzionamento a burst.
Le fifo si trovano in tutti i wizard di tutti i tool per FPGA, sono sostanzialmente delle memorie dual port di cui si utilizza una porta esclusivamente per la scrittura e l'altra solo per la lettura. I rispettivi address vengono incrementati indipendentemente, ma la parte più delicata è la creazione delle flag di controllo. Tali flag sono il risultato del confronto fra gli indirizzi di lettura e scrittura che (fai bene attenzione!) si muovono in domini di clock differenti. Non puoi trattarli allo stesso modo di tutti gli altri segnali e devi dunque adottare delle strategie sulle quali ora non credo sia il momento di perdere tempo.
Ti suggerisco dunque di usare, per ora, le fifo che ti crea il wizard (anche se normalmente preferisco evitarle). Le instanzi e le simuli per bene, cercando di capire dopo quanti colpi di clock si muovono le flag, dopo quanti escono i dati, se puoi svuotarle del tutto o riempirle del tutto e così via.
Buon divertimento!

 

[florius]

sempre molto preciso e inciso.
Grazie