VHDL (II)

VHDL, seconda parte. Bene, ora che abbiamo iniziato con il VHDL possiamo passare ad un esempio un po’ piu’ corposo, non tanto come quantita’ di codice ma come insieme di regole empiriche che pero’ aiutano a cavarci d’impaccio.

Un progetto VHDL

Le prime regole d’oro in questo tipo di progettazione sono:
1) Non cominciare a progettare senza prima aver riflettuto sull’intero progetto, per meglio dirla approcciamo la progettazione VHDL in modo top-down. Pensiamo come possiamo dividere il nostro progetto VHDL e cominciamo a specificare il singolo modulo.
2) Dove possibile impieghiamo strutture di programma autoesplicative come il case, hanno il vantaggio di essere formalmente eleganti e di essere appunto autoesplicative, lo svantaggio e’ che alcune volte non sono ottimizzate ma tanto la tecnologia ci aiutera’ sempre di piu (maggiore logica, piu’ memoria, piu’ velocita’)’. Evitiamo l’uso di nomi di variabili generiche (leggi pippo oppure pluto o simili) il secondo risparmiato per pensare al nome piu’ conacente non paga
3) Impieghiamo dove possibile le unita’ di controllo, sono uno strumento estremamente potente che ci trarra’ d’impaccio sempre
4) Il progetto deve essere rigorosamente sincrono, io aggiungerei impiegando un solo clock (anche se probabilmente questa seconda imposizione alcune volte e’ pesante). Anche il requisito di progettare un hw rigorosamente sincrono puo’ venir meno, ma, in questo caso, aspettatevi una difficolta’ di progettazione maggiore e cosi’ anche per il testing VHDL.
5) Ogni volta che si fa’ una modifica “importante” non dimenticarsi di rifare un controllo a 360° del progetto, non si sa’ mai se c’e’ una soluzione piu’ valida.
6) Ricordatevi di cambiare revisione prima di ogni cambiamento o implementazione radicale del progetto. Io, in genere, copio l’inter directory di lavoro piuttosto che il singolo file.

Io proverei a discutere il progetto VHDL, come esempio, di una macchina distributrice di bevande.
Vediamo le specifiche:
- Vogliamo poter selezionare uno di tre prodotti, i quali hanno un costo diverso fra loro gestendo le monete, il resto e il livello del bene che si sta acquistando.

Progettazione top-down
1) Ci sara’ un processo che gestira’ la gettoniera in ingresso, con i relativi pagatori (hopper) per il resto.
2) Ci sara’ un processo responsabile della selezione del prodotto
3) Ci sara’ un processo che provedera’ a dispensare il prodotto selezionato
4) Ed infine ci sara’ un processo con funzioni di direttore di orchestra che gestira’ il tutto
Qualcuno puo’ obiettare che per un progetto cosi’ semplice si puo’ fare un’unica macchina a stati che gestisca il tutto, e’ vero pero’ io preferisco fare una macchina a stati semplice (pochi stati) cosi’ e’ molto confinata e non corro il rischio di fare “casino” da altre parti.
La sequenza di queste azioni sara’ gestita da una unita’ di controllo. Giusto per ricordare anche la teoria le macchine a stati finiti vengono etichettate come macchine di Mealy o di Moore.
Gli stati sono (io uso identificare gli stati con il loro indirizzo, cioe’ s0=0, questo aiuta durante la simulazione, ma ogni altra tecnica e’ valida):
- Stato S0, ci si arriva dal reset, e vengono messi in condizioni di default i segnali da generare
- Stato S1, si esegue il test se il cliente ha selezionato un prodotto, nel caso che nulla sia stato selezionato si resta in S1
- S2, si aspetta che il cliente introduca le monete richieste, altrimenti si aspetta in S2
- S3, si provvede a fornire la distribuzione e si passa nello stato successivo
- S4, si attende l’erogazione della consumazione
- S5, si eseguono le operazioni di fine e si ritorna in S1
Quando costruiamo una unita’ di controllo dobbiamo vedere con la mente come sara’ realizzato l’HW, in genere questo aiuta a capire cosa stia accadendo quando si verifica un errore o di compilata o di simulazione.
L’indirizzo attuale e’ contenuto in un registro (che prende il nome di registro di stato appunto), gli ingressi di questo registro provengono da una rete di MX la cui selezione e’ funzione dello stato attuale, cioe’ in generale il registro carichera’ un indirizzo che risulta dato dalla condizione esterna selezionata dal valore di indirizzo attuale.
L’uscita del registro di stato, cioe’ l’indirizzo corrente, viene decodificato e fornisce i segnali di output.
Qualche accenno a possibili modifiche
Per chi fosse amante del complesso si puo’ aggiungere che il registro di stato puo’ essere rappresentato anche da un contatore e cio’ permette di ottenere le condizioni di test che possono essere:
- load (caricamento di un nuovo indirizzo)
- count (salto all’indirizzo +1)
- hold (stop sull’indirizzo attuale)

Si immagini le istruzioni di branch di un computer generico quali:
- if(sign =0 ) pc=pc+1 (puo’ far comodo un contatore)
else pc=add;
Ovviamente il registro di stato puo’ anche essere in parte un registro e in parte un contatore e cosi’ via.

Leggi anche: VHDL I e VHDL III

Repost: 29 Lug 2008

Scarica subito una copia gratis
Tags:,

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend