Siamo arrivati finalmente ad una fase fondamentale di questo corso: il VHDL. Il linguaggio di descrizione hardware più utilizzato in Italia ci permetterà di utilizzare le FPGA fino al più nascosto transistor. Mettetevi comodi: che lo spettacolo abbia inizio!
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2686 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.
Ti potrebbe interessare anche:
Cronjob PHP: come usarli per generare automaticamente report dati nel mondo IoT
Tecnologie per la stampa 3D: Parte 1
La tecnologia blockchain nelle applicazioni robotiche
OPAMP e segnali video: ecco come scegliere il giusto operazionale
Metodo della funzione descrittiva per lo studio di un Ring Oscillator
Grazie mille per questo utilissimo corso di introduzione al vhdl
Grazie mille a te Andres, è davvero gratificante sapere di essere stato utile e a qualcuno.
Preciso però una cosa: non lo definirei “corso”, come detto nell’articolo, il VHDL non può essere appreso attraverso un articolo. Ciò che mi è sembrato utile dover fare è incuriosire, stimolare, segnare un percorso in modo grossolano in modo che gli appassionati di elettronica abbiano una direzione, un obiettivo da guardare. Tutto il resto può essere imparato solo attraverso dei corsi specifici piuttosto lunghi (e che non credo di essere in grado di fare), oppure con la passione di chi riesce ad essere autodidatta. Inoltre ho inserito dei consigli preziosi, che invece un corso di VHDL difficilmente può dare, specialmente i corsi trovati in rete, perché non tutti gli esperti di VHDL sono esperti di FPGA (ahimé). Io ho cercato di mettere al vostro servizio la mia esperienza, più che le mie conoscenze.
Grazie a una segnalazione di un utente, ho notato come ci sia un aspetto che potrebbe non essere chiaro nel mio articolo, e che vorrei chiarire subito.
Il linguaggio VHDL permette di utilizzare delle librerie, standard o meno, che i software possano interpretare.
In particolare queste librerie permettono all’utente di utilizzare tante funzioni che NON SONO IL LINGUAGGIO, ma che il linguaggio permette di utilizzare. Una di queste librerie è la sopracitata IEEE.std_logic_1164.all.
Per spiegare meglio il problema, vi invio il link che mi ha mandato l’utente tazzo:
http://electro-logic.blogspot.it/2013/09/fpga-approfondiamo-il-confine-tra-il.html
Per chi è interessato a comprendere meglio questa problematica, vi consiglio di dare un occhiata al link riportato, dato che spesso c’è confusione tra librerie standard e linguaggio.
Un grazie a Leonardo.
Tiziano
Un passaggio di questo articolo mi ha colpito particolarmente. Ad un certo punto si dice:
“C’è una scuola di pensiero, che abbraccio completamente, che ritiene fondamentale per un’azienda che chi realizza il sistema e chi realizza il testbench debbano essere due persone diverse e scorrelate (nel senso che meno si scambiano informazioni e meglio è). Immaginate il caso in cui il progettista ha compreso male una specifica, realizza il sistema in base a questa, poi magari inizia a fare un testbench in base a quello che ha capito, e magari limitato a quello che secondo lui è importante testare…. i possibili errori si moltiplicano a dismisura!!!”
Vorrei fare una domanda: si tratta di un caso di ridondanza? Oppure di un meccanismo di controllo in parallelo?
Cioè, questo diciamo espediente rientra nei sistemi e nei metodi di controllo della qualità e (soprattutto) prevenzione?
Forse in un certo senso si può dire che si tratta di ridondanza, o meglio, di ridondanza della verifica e della qualità.
Generalmente, al momento di realizzare un progetto, esistono delle specifiche più o meno chiare. A questo punto interviene la comprensione delle specifiche, che sta al progettista.
Se per qualche motivo il progettista ha compreso male qualcosa, questa errata comprensione va a inficiare il progetto. Se poi è lui che fa il testbench, certamente il testbench sarà fatto secondo le specifiche comprese, e se c’è un errore si ripercuoterà anche su di esso, per cui non mostrerà l’errore di progetto.
Altra cosa che va poi detta è che il progettista ha un debole per il proprio lavoro, cioè vuole dimostrare che questo funzioni. E’ un meccanismo mentale che spesso interviene. Per spiegare il problema, faccio un esempio “profano”: quante volte vedete un calciatore lamentarsi con l’arbitro che gli ha fischiato un fallo non fatto, che poi in realtà, vedendolo al rallenty, si vede in modo chiaro che lo ha fatto? E’ un meccanismo di autodifesa e autogiustificazione che ha il nostro cervello.
Questo può far sì che il testbench venga fatto non per dimostrare la correttezza del sistema realizzato, ma per “mostrare” che il sistema sia corretto. Spero di essere stato chiaro e di aver risposto al tuo dubbio.
Scusa Tiziano come posso scaricare l’articolo in formato pdf ?
Grazie e complimenti.