VHDL per FPGA Courtesy of S. Mattoccia

Introduzione HDL VHDL (progetto DoD) e Verilog (iniziativa privata) Linguaggi ad alto livello finalizzati alla simulazione di circuiti digitali ma sempre più utilizzate (anche) per la sintesi L’obiettivo è rendere la progettazione dei sistemi digitali più efficace (riducendo i tempi e i costi di sviluppo, consentendo la gestione di progetti di grandi dimensioni, etc) I linguaggi di tipo HDL consentono di gestire il comportamento dell’hardware intrinseco parallelismo e ritardi Tipicamente utilizzati per programmare gli FPGA Utilizzati anche per realizzare ASIC, processori, etc VHDL - Very High-level Design Language Nel prosieguo comunque verrà presentata una parte del linguaggio, anche con alcune volute imprecisioni se utile per una semplice progettazione FPGA

Introduzione VHDL Il VHDL è un linguaggio che ha mutuato i costrutti tipici del C ma con tutte le modifiche necessarie al contesto cui fa riferimento Come nel caso Altera è disponibile un ambiente di sviluppo software e simulazione Per motivi di semplicità nell’uso del simulatore e di completezza della panoramica verrà utilizzato il sistema di sviluppo Xilinx (concorrente di Altera) Per l’uso consultare il file Xilinx 11 tutorial.PDF inserito sul sito in radice dei files di Reti logiche

Hardware Software Personal computer con SO Windows o Linux* Possibilmente una connessione a banda larga (non strettamente necessaria) Software Sistema di sviluppo Xilinx liberamente disponibile (per SO Windows e Linux*)

Software Xilinx Scaricare dal sito del corso di Calcolatori M (cartella Software) il software di progetto. Vi sono sia le versioni complete (.TAR) che quelle scompattate (ricompattabili con il software Free-File-Splitter-v5.0.1189.exe disponibile sul sito). Il software 11.1 è comune a Windows (32 bit) e Linux (32 bit) metre l’uodate 11.5 è differenziato. Installare il software 11.1 eseguendo il programma di installazione xsetup.exe e selezionando l’opzione WebPack Installare in seguito il software 11.5 differenziato fra Windows e Linux (sempre a 32 bit) Nelle pagine successive sono mostrati gli screenshots relativi alle fasi di installazione N.B. Le installazioni possono prendere anche più di un’ora !!! Effettuarle con la connessione a Internet attiva. A breve sarà inserito sul sito la nuova versione 12.1 (tempi incerti ancora) N.B. FAT32 non supporta files > 4 GB. Il programma ISE nella sua versione attuale permette anche la realizzazione di schematici come in Altera ma è uno strumento meno sofisticato e che sarà abbandonato nelle versioni successive in favore della sola realizzazione VHDL . Anche Altera permette la sintesi con VHDL ma la simulazione NON è embedded nel sistema e obbliga a utilizzare un altro programma (ModelSim). NON è possibile installare il software sotto “Program Files” ma solo in radice

1/9

2/9

3/9

4/9

5/9

6/9

7/9

8/9

9/9

FPGA vs progetto hardware tradizionale Le moderne metodologie di progettazione basate su FPGA e HDL consentono di ridurre notevolmente il time to market rispetto ad un progetto hardware tradizionale. Infatti, l’INTERO sviluppo del prototipo è eseguito al calcolatore. Il costo di produzione di un progetto basato su FPGA potrebbe essere più oneroso, ad esempio, rispetto ad una realizzazione ASIC (Application Specific Integrated Circuit). Nonostante questo, essendo il VHDL uno standard è possibile realizzare ASIC a partire dal codice VHDL utilizzato per lo sviluppo del prototipo su FPGA. Un FPGA può essere riconfigurato (nuova programmazione) sul campo in caso di bachi o per inserire nuove funzionalità

Progettazione con VHDL e FPGA entity my_AND is Port (A : in BIT; B : in BIT; Z : out BIT); . . . end my_AND Design Entry A Z B Simulazione Primo elemento: entity definisce i pins di ingresso e uscita del sistema come una black-box A B Z t Mapping su FPGA

Caratteristiche del linguaggio VHDL (HDL in generale) Il VHDL, essendo un linguaggio di programmazione finalizzati a modellare l’HARDWARE, presenta delle sostanziali differenze logiche rispetto al C. Qui infatti in generale (come meglio spiegato nel prosieguo) gli statements (laddove ne ricorrano le condizioni) sono eseguiti tutti in parallelo come avviene nella realtà fisica che descrivono (tutti gli elementi di una rete operano in parallelo e non in serie) La capacità “eseguire” più operazioni contemporanee, tipica dei dispositivi hardware Concorrenza La capacità di modellare i tempi di propagazione dei segnali all’interno dei circuiti digitali Timing

Timing e Concorrenza Rete ideale La propagazione dei segnali avviene attraverso fili o bus. Nella realtà la propagazione dei segnali NON avviene istantaneamente perché ritardata dalle caratteristiche fisiche delle connessioni/componenti (fenomeni parassiti, ritardi dei gates, etc). Si consideri ad esempio la seguente rete logica: C Z Rete ideale Volendo descrivere come si propaga il segnale con un linguaggio di programmazione ad alto livello (ad esempio con il C) si potrebbe pensare di scrivere a <=x; -- assegna x a a z<=a and c; -- assegna z Con questi due statements NON è vero che allo stesso istante x=a e z=ac !!!! Z cambierà in seguito, dopo il ritardo del NAND

PROBLEMA DI CONCORRENZA: I linguaggi di programmazione tradizionali prevedono che due istruzioni di assegnazione vengano eseguite nella sequenza in cui compaiono nel programma. Nella realtà il segnale elettrico parte da x e si propaga contemporaneamente verso a e b (non prima su a e poi su b come avverrebbe con il codice della pagina precedente scritto in C). PROBLEMA DI TIMING: Le due assegnazioni del lucido precedente non contemplano i ritardi di propagazione del segnale (nel caso di figura 3 e 4 ns) e il ritardo introdotto dai gates tipici di una rete reale. 3 4 Rete reale: percorsi diversi impongono la variazione dei segnali a e b in ritardo e in istanti diversi rispetto alla variazione del segnale x. Nei sistemi per la progettazione FPGA i ritardi sono quelli dati dalla tecnologia del circuito

a<=x after 4*unit_delay b<=x after 3*unit_delay Considerando la rete dell’esempio precedente. Se ogni tratto del circuito introduce un ritardo pari a 1 unit_delay () il codice VHDL che descrive il funzionamento reale della rete potrebbe essere : a<=x after 4*unit_delay b<=x after 3*unit_delay Le due istruzioni in VHDL sono eseguite contemporaneamente (esecuzione concorrente) t x a b  N.B. il comando after così come il comando wait nel sistema Xilinx può essere utilizzato SOLO nei testbenches (v. dopo) in quanto nel nostro caso il VHDL è usato per progettare e non per descrivere

Quando un programmatore scrive del codice con un linguaggio ad alto livello (C/C++, Java, etc) immagina di scomporre il problema in una serie di istruzioni che saranno eseguite in modo sequenziale (paradigma di programmazione sequenziale). Al contrario, un progettista hardware decompone il progetto in blocchi interconnessi che reagiscono ad eventi e a loro volta generano eventi. Gli eventi sono le transizioni dei segnali: un ingresso, un’uscita o il clock sono possibili eventi. Questo impone che tutti i blocchi “dipendenti” da tali eventi siano valutati in base ai nuovi valore dei segnali. L’ordine con il quale vengono valutati i blocchi deve essere ininfluente sul risultato finale (ovvero, qualunque sia l’ordine di valutazione dei singoli blocchi, lo stato complessivo raggiunto dalla rete quando tutti gli eventi sono stati gestiti deve essere sempre il medesimo). Il tipo di programmazione che consente di modellare questo tipo di funzionamento e’ il paradigma di programmazione parallela. Poiché il risultato dell’elaborazione deve essere indipendente dalla sequenza in cui le istruzioni sono state eseguite tutte le elaborazioni debbono essere eseguite in parallelo senza che mai una istruzione, per essere eseguita, debba attendere il completamento di un’altra.

Consideriamo la rete seguente e ipotizziamo che i ritardi (gates , percorsi, etc) siano identici. Il codice che descrive il funzionamento di questa rete deve generare un risultato (uscita di ciascun gate) che dipende solo dal valore degli ingressi e non dall’ordine con il quale vengono valutati gli AND e l’OR nel codice. Le istruzioni che descrivono i blocchi possono essere codificate secondo il paradigma della programmazione parallela tipico del VHDL nel modo seguente (<= sta a indicare la modifica del segnale): T1 <= A and B; T2 <= C and D; TN <= E and F; U <= T1 or T2 or T3; U <= T1 or T2 or T3; T1 <= A and B; T2 <= C and D; TN <= E and F; Equivalenti

Entità definite in VHDL In VHDL sono disponibili entità (oggetti) alle quali è associato un tipo di dato ed un valore. Costanti Variabili Segnali Vediamo ora come è possibile dichiarare e assegnare valori a Costanti, Variabili e Segnali.

constant nome: tipo := valore; constant ritardo: time := 3 ms; Costanti Entità che non possono cambiare il loro valore durante la simulazione. Utili per aumentare la leggibilità del codice constant nome: tipo := valore; Esempio di dichiarazione/assegnamento (attenzione sempre al ; alla fine dello statement) constant ritardo: time := 3 ms;

Variabili (NON segnali !!!) Oggetti che possono cambiare il loro valore durante la simulazione. Possono essere dichiarate solo all’interno di un process (vedi lucidi successivi) e sono locali al process (il valore iniziale è opzionale) variable nome: tipo [:= valore_iniziale]; Esempio di dichiarazione variable stato_iniziale: boolean := true; variable IJK: integer; Esempio di uso (IJK è la variabile) for IJK in 7 downto 3 loop – esegui 5 volte (da 7 a 3 compresi) !!! a(IJK) <= b(IJK) ; end loop; -- tutti gli statements nel loop sono eseguiti contemporaneamente NB una variabile non ha significato hardware serve solo a definire la modalità di esecuzione del programma e NON e’ un segnale Le variabili possono essere dichiarate, o avere valori assegnati, solo all’interno di blocchi sequenziali (ovvero, all’interno di process – v. dopo) e sono locali a tali blocchi. L’assegnamento è eseguito mediante l’operatore := ed è immediato Esempio z:= y; -- z e y variabili

signal nome: tipo [:= valore_iniziale]; Segnali Entità fisiche (segnali, in effetti…) che possono cambiare il loro valore durante la simulazione (il valore iniziale è opzionale) con un ritardo intrinseco alla tecnologia o a un segnale di sincronismo signal nome: tipo [:= valore_iniziale]; Esempi signal A: bit := ‘1’; signal B: bit := ‘0’; signal C: bit := ‘1’; C <= A and B; N. B. L ’assegnamento è eseguito mediante l’operatore <= e NON è immediato (ovvero, avviene dopo un tempo prestabilito, ad esempio in presenza del fronte positivo del clock ); torneremo più avanti su questo argomento

Tipi di dato predefiniti in VHDL Nel linguaggio VHDL (Standard Package) sono predefiniti i seguenti tipi di dato: bit (‘0’,’1’) -- tipico per i segnali boolean (‘TRUE’,’FALSE’) integer natural positive time Oltre ai tipi predefiniti e’ possibile utilizzarne altri includendo specifiche librerie (esempio: LIBRARY IEEE). Ad esempio, molto importante, std_logic (standard logic - meglio specificato in seguito). Ad esempio wr : in std_logic; -- signal write nella dichiarazione entity ove in sta a indicare che è un segnale di input al sistema (poteva essere out o inout) L’uso di std_logic al posto di bit è indispensabile in Xilinx se si vuole eseguire anche una simulazione timing (post-route). Con I segnali “bit” è comunque possibile la simulazione funzionale (behavioural)

Il tipo bit Un oggetto di tipo bit può assumere i valori ‘0’ e ‘1’ Esempio signal a: bit; E’ possibile anche definire dei vettori di bit mediante bit_vector Esempio signal esempio_vettore: bit_vector (7 downto 0); Per valori binari di un singolo bit si utilizza come simbolo ‘ mentre per configurazioni binarie composte da 2 o più bit si utilizza il simbolo “ Esempio a <= ‘1’; esempio_vettore <= “10011100”; Come già indicato al tipo “bit” è opportuno sostituire il tipo “std_logic” che ne è una estensione

Il tipo integer Il tipo natural Il tipo positive Il range degli integer è dipendente dalla piattaforma ma è almeno pari a [-2^31-1,2^31-1]. Esempio constant data_bus: integer:=32; Il tipo natural I natural sono numeri interi compresi tra 0 e (almeno) 2^31-1. Il tipo positive I positive sono numeri interi compresi tra 1 e (almeno) 2^31-1.

Il tipo real Il tipo time Il range real è dipendente dalla piattaforma Esempio constant pi_greco: real:= 3.14; Non verrà usato Il tipo time Al tipo time è associato un attributo (ms, us, ps, etc) ed è utilizzato quando è necessari specificare dei tempi. Esempio constant ritardo: time:= 5 ns;

Formalismo vettoriale (bus) - downto Formalismo scalare a3 ENTITY y1 a2 a1 y0 a0 port ( a3,a2,a1,a0 : in bit; y1,y0 : out bit); port ( a3,a2,a1,a0 : in std_logic; y1,y0 : out std_logic); Notare la posizione del simbolo ; e delle parentesi Formalismo vettoriale (bus) - downto MSB LSB ENTITY A[3..0] Y[1..0] port ( a : in bit_vector (3 downto 0); y : out bit_vector (1 downto 0)); port ( a : in std_logic_vector(3 downto 0); y : out std_logic_vector(1 downto 0));

E’ possibile accedere agli elementi di un vettore mediante indici Esempio: y(2) <= a(1) E’ inoltre possibile assegnare una sequenza di cifre Esempio: y <= “01”; E’ anche possibile effettuare assegnazioni ad un numero limitato di bit del vettore (bit-slicing) Esempio: y(4 downto 2) <= “101” - 1 vettore

Operatore di concatenazione & L’operatore & consente di concatenare più bit o stringhe di bit Esempio: y <= “101” & “011” & ‘1’; -- 1010111 A:=“101”; -- variabile B:= “011”; C:= ‘1’; y <= A&B&C; -- avrebbe dato lo stesso risultato Si osservi che l’operazione di concatenazione NON è una azione logica con significato fisico ma solo un mezzo per esprimere in modo più chiaro una espressione individuandone le singole componenti Operatori logici in VHDL (segnali e variabili) And: and Or: or Not: not Nand: nand Nor: nor Xor: xor Xnor: xnor Gli operatori logici agiscono sui tipi bit, boolean e std_logic L’operatore not è prioritario rispetto agli altri (equamente prioritari come nelle espressioni logiche). Ovviamente la precedenza è alterabile con l’uso di parentesi (come nelle espressioni logiche) Se sono usati vettori il numero di bit dei due operandi deve essere il medesimo. Esempi: y <= not a; z <= a and b;

Modellazione dei ritardi (segnali) Il VHDL consente di modellare i ritardi (TIMING) presenti nei testbenches. Questo è possibile mediante mediante il comando after. z<= y after 6 ns;

I passi della progettazione Schema logico Design Entry Strutturale “Structural” (Blocchi interconnessi) Descrizione Testuale (VHDL) Comportamentale “Behavioural” Compilazione Simulazione Funzionamento previsto? NO SI Mapping su FPGA

Hello VHDL x z y -- indica commenti Interface specification -- primo esempio di codice VHDL -- un semplice AND -- interface specification entity Hello_vhdl is Port ( X in bit; Y : in bit; Z : out bit); end Hello_vhdl; -- descrizione della struttura architecture Behavioral of Hello_vhdl is begin Z <= X and Y; -- effetto immediato !!! end Behavioral; -- indica commenti Interface specification (black box) x Hello_vhdl z y In blu le “reserved words” Architettura: descrizione della struttura (e del comportamento)

I commenti sono preceduti da - - Il VHDL non è case sensitive Non è possibile usare spazi nei nomi dei segnali etc Non è possibile utilizzare nomi che iniziano o terminano con “_” Non è possibile utilizzare nomi che iniziano un numero Due “_” consecutivi non sono consentiti Non è possibile assegnare parole riservate per i nomi dei segnali etc (es. segnali denominati BIT, AND etc. non sono consentiti) E’ buona norma usare l’estensione .vhd per i file VHDL Contrariamente al C/C++ non è possibile inserire commenti multi linea (necessario un - - per ogni linea) Le istruzioni terminano con “;”

Testbench Testbench E N T I Y E N T I Y Un testbench è un particolare codice VHDL (un programma per la simulazione specifica per il progetto da testare) mediante il quale è possibile analizzare la risposta di una rete a determinati stimoli di ingresso. E’ normalmente utilizzato per il test dei progetti VHDL. E’ riconducibile alla seguente architettura hardware: Testbench E N T I Y E N T I Y Risultati Stimoli Viene identificato come “component” Simulazione N.B. nel testbench il riferimento al dispositivo da testare si istanzia con il comando “component”. In effetti il dispositivo diventa un componente del sistema di test. Nei sistemi di progettazione FPGA il comando “after” e “wait” è utilizzabile solo per gli stimoli del testbench mentre i ritardi del sistema (Entity) dipendono dal tipo di FPGA scelto. In Xilinx nel momento i cui si inizia la redazione di un file VHDL (new source) bisogna specificare se è un sorgente o un testbench

Esempio di Testbench entity Testbench_di_Hello_VHDL is end Testbench_di_Hello_VHDL; architecture behavior of Testbench_di_Hello_VHDL is -- Component Declaration for the Unit Under Test (UUT) component Hello_vhdl Port (X : in bit; -- dichiarazione dei bit di input e output Y : in bit; -- del sistema (entity) sotto test indicato Z : out bit ); -- come “component” end component; --Inputs signal X_test : bit := '0'; -- dichiarazione dei segnai interi al testbench signal Y_test : bit := '0'; -- facenti parte dell’architecture. Non vi è -- dichiarazione di port di input o output nella entity -- del testbench --Outputs signal Z_test : bit; Component Segnali interni al testbench

-- Instantiate the Unit Under Test (UUT) begin -- Instantiate the Unit Under Test (UUT) uut: Hello_vhdl PORT MAP ( X_test=> X, -- corrispondenza fra i segnali Y_test => Y, -- interni al testbench e i segnali Z _test=> Z ); -- del “component” -- Stimulus process stim_proc: process -- reset for 100ms. wait for 100ms; -- aspetta 100 ms. -- wait ammesso nel testbench -- inserzione degli stimoli -- NB in presenza di wait (o after) gli stimoli sono eseguiti in sequenza -- Wait e After permessi solo nei testbenches X_test<='1'; Y_test<='0'; wait for 10 ms; X_test<='1'; Y_test<='1'; wait for 10 ms; wait; -- forever. La simulazione qui si ferma end process; end; Corrispondenza (collegamento”) fra i segnali del dispositivo e quelli del Testbench I segnali interni possono avere lo stesso nome di quelli del dispositivo (come nel caso della simulazione riportata)

Tipica struttura del codice VHDL (progetto - non testbench) library IEEE; use IEEE.std_logic_1164.all; -- necessario per l’uso di std_logic -- Entity declaration entity nome_entity is Port (signal_name : direction type); end nome_entity; -- Architecture description architecture architettura_entity of nome_entity is <architecture declarations> begin <processing statements> end architettura_entity ; Inclusione librerie Interface specification A z B S Architectural specification

Interface specification (Entity) entity nome_entity is Port(signal_name: direction type); end nome_entity; Port consente di specificare: signal_names: quali sono i segnali della rete direction: quali segnali sono di input (in), output (out) , bidirezionali (inout), utilizzabili internamente type: il tipo di segnale (bit, std_logic, bit vector, std_logic_vector …)

Architectural specification (Architecture) architecture architettura_entity of nome_entity is <architecture declarations> begin <processing statements> end architettura_entity ; All’interno della sezione architecture è specificata la logica della rete. All’interno della sezione architecture (in <architecture declarations>) è possibile definire degli oggetti. Tali oggetti sono tipicamente dei segnali e possono essere utilizzati (scope) solo all’interno della architecture description I segnali interni a una architettura sono da inserire dopo begin e prima di process Le variabili sono invece locali a un processo (se esiste) E’ possibile utilizzare sia data types definiti in VHDL sia data types presenti in librerie aggiuntive. Ad esempio: signal T1,T0 : bit; signal T3,T4 : std_logic; Si noti che la dichiarazione signal è diversa da quella implicita in Port (v. esempio a pagg. 39 e 40) ove è indispensabile indicare la direzione. La parte nella quale viene specificata la logica della rete è compresa tra begin e end.

Assegnamento dei segnali e “Delta delay” In VHDL è necessario prestare molta attenzione al fatto che l’aggiornamento di un segnale NON è istantaneo Nel caso non siano esplicitamente inseriti dei ritardi, (clock - oppure statement after, wait nei testbenches), durante la simulazione i nuovi valori dei segnali sono aggiornati con un ritardo denominato delta delay che per i sistemi FPGA è determinato intrinsecamente dalla loro tecnologia Il meccanismo di aggiornamento mediante delta delay è il medesimo sia con statements concorrenti che sequenziali Le variabili non i segnali possono essere aggiornate immediatamente. Le variabili NON hanno significato fisico. Ad esempio a e b siano segnali e I una variabile I := I+1 -- immediato a <= b -- dopo il ritardo intrinseco della rete Se la rete è sincrona rispetto a un segnale di clock (o altro segnale di sincronismo, ad esempio il cambiamento di una segnale (NON di una variabile) la variazione di a sia ha solo in occasione dell’evento (se clock – ad esempio - al fronte positivo o negativo selezionabile) Un errore tipico è quello di assegnare un valore ad un segnale e poi testare una condizione sul valore del medesimo segnale. Il test fornisce un risultato erroneo in quanto avviene contemporaneamente allo statement di assegnazione. Il segnale non verrà aggiornato prima di un delta delay (in mancanza di altri ritardi come after) o di un periodo di clock e insieme a tutti gli altri segnali !

Statement when-else <signal_name> <= <signal/value> when <condition1> else <signal/value> when <condition2> else . . . . . . . . <signal/value> when <conditionN> else <signal/value>; Nel caso siano verificate più condizioni al segnale è signal_name assegnato il primo valore che soddisfa la condizione (in ordine di apparizione nel codice – analisi sequenziale ….) when Attenzione all’ultimo else: se omesso, nel caso di reti combinatore, potrebbe involontariamente dare luogo ad un comportamento non combinatorio (quando nessuna delle condizioni è verificata, per il segnale per cui si esegue <=, viene mantenuto il valore precedente per cui si avrebbe un effetto memoria)

Esempio di codice VHDL per modellare un AND a 2 ingressi utilizzando il costrutto when-else ENTITY and2 IS PORT (a, b : IN BIT; y : OUT BIT); END and2; ARCHITECTURE arch_and2 OF and2 IS BEGIN y<='1' WHEN (A='1' AND B='1') ELSE '0'; END arch_and2; Esempio (and2)

Codice VHDL alternativo per modellare un AND a 2 ingressi utilizzando il costrutto when-else ENTITY and2whenelse1 IS PORT (a : IN BIT_VECTOR (1 DOWNTO 0); y : OUT BIT); END and2whenelse1; ARCHITECTURE arch_and2whenelse1 OF and2whenelse1 IS BEGIN y <= ‘0' WHEN a(0)=‘0’ ELSE ‘0' WHEN a(1)=‘0’ ELSE ‘1’; END arch_and2whenelse1; Esempio (and2)

Un’alternativa, sempre utilizzando when-else, potrebbe essere la seguente.. ENTITY and2whenelse2 IS PORT (a : IN BIT_VECTOR (1 DOWNTO 0); y : OUT BIT); END and2whenelse2; ARCHITECTURE arch_and2whenelse2 OF and2whenelse2 IS BEGIN y <= ‘0' WHEN a(0)=‘0’ ELSE ‘ 1' WHEN a(1)=‘1’ ELSE -- a(0) è già stato verificato non 0 ‘0’; END arch_and2whenelse2; Esempio (and2)

Oppure... ENTITY and2whenelse3 IS PORT (a : IN BIT_VECTOR (1 DOWNTO 0); y : OUT BIT); END and2whenelse3; ARCHITECTURE arch_and2whenelse3 OF and2whenelse3 IS BEGIN y <= ‘1' WHEN a=“11” -- notare “ e non ‘: a è un vettore cui si assegnano ELSE ‘0’; -- due valori in questo caso END arch_and2whenelse3; Esempio (and2)

Statement with-select-when with <expression> select <signal_name> <= <signal/value> when <condition1>, <signal/value> when <condition2>, . . . . <signal/value> when others; Tipicamente un segnale o un vettore Tutte le condizioni sono verificate contemporaneamente (diverso comportamento rispetto a when-else) se vi è SELECT Nel caso più condizioni siano verificate, queste debbono essere raggruppate (altrimenti si avrebbe un (illecito) assegnamento multiplo al segnale con risultato impredicibile) l’opzione when others consente di gestire i casi di nessuna condizione verificata

Esempio di codice VHDL per modellare un AND a 2 ingressi utilizzando il costrutto with-select-when ENTITY and2with IS PORT (a : IN BIT_VECTOR (1 DOWNTO 0); y : OUT BIT); END and2with; ARCHITECTURE arch_and2with OF and2with IS BEGIN WITH a SELECT y <= ‘1' WHEN "11", ‘0' WHEN “00”, ‘0' WHEN “01”, ‘0' WHEN “10”; END arch_and2with; Esempio (and2)

Una realizzazione più semplice potrebbe essere: ENTITY and2withothers IS PORT (a : IN BIT_VECTOR (1 DOWNTO 0); y : OUT BIT); END and2withothers; ARCHITECTURE arch_and2withothers OF and2withothers IS BEGIN WITH a SELECT y <= ‘1' WHEN ”11", ‘0' WHEN OTHERS; END arch_and2withothers; Esempio (and2)

Caso di studio: Latch SR Prendiamo in esame il latch SR, una semplice rete sequenziale asincrona. S R Q Q* S R 1 Q QN Q* SR S R Q QN Q = !(R + ! (S + Q)) I comandi di set (S) e reset (R) debbono avere una durata minima (raggiungimento della stabilità) La configurazione S=1, R=1 non è ammessa (non proibita ma causa un funzionamento anomalo del latch)

! Latch SR_1 (buffer) entity Latch_SR_1 is Port ( S : in bit; R : in bit; Q : buffer bit; QN :buffer bit); end Latch_SR_1; architecture Behavioral of Latch_SR_1 is begin Q <= R nor QN; QN <= S nor Q; end Behavioral; ! Un segnale di uscita (out) non può essere utilizzato internamente alla rete Per questo motivo le uscite Q e QN sono dichiarate di tipo buffer (vale come input e output - sconsigliabile)

Gli strumenti di sintesi segnalano che le uscite dichiarate come buffer potrebbero creare problemi in fase di simulazione (il compilatore dà degli “warnings” e non permette la simulazione timing) A questo fine, con il prossimo esempio, vedremo come sia possibile evitare di dichiarare uscite di tipo buffer

Latch SR_2 (no buffer) entity Latch_SR_2_no_buffer is Port ( S : in bit; -- per la simulazione timing utilizzare std_logic R : in bit; Q : out bit; QN : out bit); end Latch_SR_2_no_buffer; architecture Behavioral of Latch_SR_2_no_buffer is signal QN_retroazione : bit := '0'; ; -- segnali interni -- per la simulazione timing utilizzare std_logic signal Q_retroazione : bit := ‘1'; begin Q_retroazione <= R nor QN; QN_retroazione <= S nor Q; Q <= Q_retroazione; -- assegna lo stato all'uscita QN <= QN_retroazione; -- assegna lo stato all'uscita end Behavioral; ! ! Per evitare di dichiarare un’uscita buffer assegniamo al segnale di uscita il segnale utilizzato internamente per la retroazione (ma si potrebbe usare std_logic inout)

Cosa accade se si utilizza la configurazione non ammessa per il latch SR ?

Latch SR_3 (behavioral, when-else) entity Latch_SR_3 is Port ( S : in bit; R : in bit; Q : out bit; QN : out bit); end Latch_SR_3; architecture Behavioral of Latch_SR_3 is signal Q_internal : bit; signal QN_internal: bit; begin Q_internal <= '1' when (S='1' and R='0') else -- when senza select '0' when (S='0' and R='1') else-- esame in sequenza Q_internal; -- e quindi alternativa QN_internal <= '0' when (S='1' and R='0') else '1' when (S='0' and R='1') else QN_internal; Q <= Q_internal; QN <= QN_internal; end Behavioral;

Per quale motivo il latch di questo esempio gestisce la configurazione di ingresso non lecita in questo modo …. ? Guardando il codice si vede che la condizione S=R=1 mantiene i valori precedenti di Q e QN (clausola else finale). Come andrebbe modificato il codice per garantire il comportamento voluto ?

Operatori relazionali definiti in VHDL Tali operatori agiscono su operandi dello stesso tipo e ritornano un valore BOOLEAN (TRUE o FALSE). Uguale: = Diverso: /= Minore: < Minore Uguale: <= Maggiore: > Maggiore Uguale: >= Esempi: a_boolean <= operand_1 > operand_2; b_boolean <= operand_1 /= operand_2;

Elaborazione Process: sensitivity_list Le espressioni comprese tra begin ed end vengono elaborate tutte contemporaneamente. Non ha alcun significato l’ordine con il quale appaiono nel codice VHDL Mediante lo statement process (usato praticamente sempre nei progetti reali) e’ possibile definire un insieme di istruzioni (o di costrutti sequenziali – ex. if-then-else -) che saranno eseguiti se uno segnali che caratterizzano la sensitivity list (v. sotto) cambia All’interno di un singolo blocco che fa parte del process (ad esempio, if, case, for etc. v. dopo) le istruzioni sono elaborate in modo sequenziale dall’alto verso il basso (nell’ordine in cui vengono scritte). Ovviamente i vari blocchi sono invece eseguiti in modo concorrente, salvo la presenza di wait o after Ogni processo e’ eseguito in modo concorrente rispetto ad altri processi o istruzioni concorrenti definite nell’architecture. Process: sensitivity_list Lista dei segnali (eventi) ai quali le istruzioni del processo sono sensibili. Rappresentano quindi gli eventi (normalmente cambi di stato) che possono modificare le espressioni definite all’interno di un processo. Se nessuno di questi eventi si verifica il processo rimane inattivo. Esempio: Synchronous: process (Counter, Force, PC, Clk , Mem)

Sequential Statements Sequential statements possono essere utilizzati solo all’interno di processi (PROCESS), funzioni (FUNCTION) e procedure (PROCEDURE) L’insieme delle istruzioni che compongono un processo costituiscono un concurrent statement if-then-else if-then-elsif-else case-when-others wait loop

Esempio processo_esempio_1: process(sensitivity list) begin assegnamento -- operazione a if then else -- operazione b assegnamento -- operazione c for loop -- operazione d case when others -- operazione e ----------------- end process processo_esempio_1; processo_esempio_2: process(sensitivity list) begin assegnamento -- operazione a if then else -- operazione b assegnamento -- operazione c wait 10 ns for loop -- operazione d case when others -- operazione e ----------------- end process processo_esempio-2; Nell’esempio 1 Le operazioni a,b,c,d,e etc sono eseguite in parallelo ma gli statements al loro interno sono eseguiti sequenzialmente. Lo stesso avviene nell’esempio 2 ma qui le operazioni d,e causa del wait sarebbero ritardate rispetto all’insieme di operazioni precedenti. L’insieme di operazioni a,b,c e l’insieme d,e sono eseguite reciprocamente contemporaneamente N.B. ricordare che wait come after si può usare in Xilinx solo nei testbenches

Statement if-then-else if <condition> then <istruzione1>; else <istruzione2>; end if; Lo statement if-then-else e’ utilizzato per eseguire un set di istruzioni selezionate sulla base del valore di una espressione booleana (<condition>). Esempio: processo_1: process(a) begin if a =‘1’ then z <=‘1’; else z <=‘0’; end if; end process processo_1; La “condition” potrebbe essere anche su una variabile (ad esempio nell’ambito di un loop per un particolare valore della variabile)

Mux 2 vie (if-then-else) 1 A B Z S entity Mu_2_vie_if_then_else is Port ( A : in bit; B : in bit; S : in bit; Z : out bit); end Mu_2_vie_if_then_else; architecture Behavioral of Mu_2_vie_if_then_else is begin processo: process(A,B,S) if S='1' then Z<=A ; else Z<=B; end if; end process processo; end Behavioral;

Cosa sarebbe successo se non avessimo esplicitamente inserito nella sensitivity list del processo i segnali A e B ? Vedi lucido successivo...

processo: process(S) La simulazione evidenzia un comportamento NON corretto nonostante in fase di sintesi sia stato generato un warning nel quale si affermava che nella sintesi della rete si sarebbero considerati anche i segnali omessi. Inserire sempre tutti i segnali (utili) nella sensitivity list di un processo !

Statement if-then-elsif-else if <condition_1> then <istruzione_1>; elsif <condition_2> then <istruzione_2>; . . . . . . . . elsif <condition_n-1> then <istruzione_n-1>; else <istruzione_n>; end if; Lo statement if-then-else può essere ulteriormente espanso al fine di consentire la valutazione di più condizioni mediante l’utilizzo di elsif. Si noti come l’esecuzione di <instruzione_i> sia subordinata alla mancata verifica di tutte le altre condizioni (i-1, i-2, ..., 1). Esecuzione sequenziale !!!

Mux 4 vie (if-then-elsif-else) 11 10 A B Z S(1) S(0) 01 00 C D entity Mux_4_vie_if_then_else_elseif is Port ( S : in bit_vector (1 downto 0); A : in bit; B : in bit; C : in bit; D : in bit; Z : out bit); end Mux_4_vie_if_then_else_elseif; architecture Behavioral of Mux_4_vie_if_then_else_elseif is begin processo: process(A,B,C,D,S) if S="11" then Z<=A; elsif S="10“ then Z<=B; elsif S="01“ then Z<=C; else Z<=D ; end if; end process processo; end Behavioral;

Si noti che ISIM rappresenta i vettori con diagrammi ad occhio Si noti che ISIM rappresenta i vettori con diagrammi ad occhio. E’ sempre però possibile separare i segnali o formare dei nuovi gruppi. Spesso gli zeri precedenti valori binari numerici sono omessi

Statement case-when-others case <selection_signal> is when <value_1> => <istruzione_1>; when <value_2> => <istruzione_2>; when <value_3> => <istruzione_3>; .. .. .. .. .. .. when <value_n-1> => <istruzione_n-1>; when others => <istruzione_n>; end case; Lo statement case-when e’ utilizzato per eseguire un determinato set di istruzioni selezionate sulla base del valore del segnale <selection_signal>. Mediante others è possibile eseguire l’istruzione <istruzione_n> quando nessuna delle condizioni è verificata.

Mux 4 vie (case-when-others) 11 10 D(3) D(2) Z S(1) S(0) 01 00 D(1) D(0) entity Mux_4_vie_case_when_others is Port ( S : in bit_vector (1 downto 0); D : in bit_vector (3 downto 0); Z : out bit); end Mux_4_vie_case_when_others; architecture Behavioral of Mux_4_vie_case_when_others is begin processo: process(S,D) case S is when "11" => Z <= D(3); when "10" => Z <= D(2); when "01" => Z <= D(1); when "00" => Z <= D(0); end case; end process processo; end Behavioral;

Nel codice del lucido precedente si sarebbe ottenuto lo stesso comportamento sostituendo when "00" => Z <= D(0); con when others => Z <= D(0);

Loop Il costrutto for <variabile> in <valore iniziale> downto <valore finale> loop oppure for <variabile> in <valore iniziale> to <valore finale> è di semplice interpretazione. Le operazioni all’interno del costrutto sono tutte eseguite contemporaneamente. Esempi (I è una variabile integer e val_max_index una costante integer) for I in 0 to val_max_index -1 loop A(I) <= B(I) or B(I+1); -- ovviamente A e B sono stati definiti come vettori end loop; In un testbench per generare una forma d’onda ripetitiva (1000 periodi di clock ad esempio) Ovviamente clock è un segnale for I in 999 downto 0 loop clock <= ‘1’; wait for 10 ns; clock <= ‘0’; wait for 10 ns; end loop;

Generazione di segnali periodici con wait Lo statement wait è tipicamente utilizzato nei testbench per generare segnali periodici. Ad esempio: CK_process :process begin CK <= '0'; wait for 5 ns; CK <= '1'; wait for 5 ns; end process CK_process; t CK 10 ns Oppure... CK_process :process begin CK <= not(CK); wait for 5 ns; end process CK_process;

Segnali di tipo STD_LOGIC l’IEEE con la libreria (standard) STD_LOGIC_1164 definisce 9 possibili valori elettrici che possono essere assunti da un segnale. Per poter utilizzare il tipo STD_LOGIC è necessario includere il file STD_LOGIC_1164 mediante: LIBRARY ieee; use ieee.std_logic_1164.all Nella LIBRARY IEEE sono definiti altri tipi e funzioni di notevole utilità(i.e. – id est - funzioni di conversione). NB l’uso di std_logic al posto di bit per i segnali è necessario in Xilinx se si vuole usare la simulazione timing (in Xilinx post-route)

I 9 valori che un segnale STD_LOGIC può assumere: type std_logic is (‘U’, -- non inizializzato ‘X’, -- sconosciuto ‘0’, -- 0 ‘1’, -- 1 ‘Z’, -- alta impedenza – tristate….. ‘W’, -- sconosciuto (debole) ‘L’, -- 0 (debole) ‘H’, -- 1 (debole) ‘-’), -- indifferente NB con questo “tipo” è possibile effettuare somme e sottrazioni fra vettori che vengono in tal caso considerati nei loro valori binari Esempio signal: addendo_6 std_logic_vector (5 downto 0) := “010010”; -- 18 signal : addendo_2 std_logic_vector (1 downto 0) := “11”; -- 3 signal : risultato std_logic_vector (5 downto 0) ; risultato <= addendo_6 – addendo_2; -- in risultato troviamo “001111” ovvero 15

Molti altri attributi qui non analizzati Attributi dei segnali Al fine di poter controllare l’evoluzione dei segnali è possibile associare ai segnali degli attributi. Una transaction su un segnale si verifica ogni volta che viene assegnato un valore a quel segnale (anche se il nuovo valore coincide con il valore precedente). Un event su un segnale si verifica ogni volta che viene assegnato un nuovo valore a quel segnale (in questo caso il nuovo valore differisce dal valore assegnato precedentemente). S’event: un segnale booleano che è TRUE se si verificano degli eventi sul segnale S (0->1, 1->0, ma non solo..) . L’attributo ‘event è tipicamente utilizzato per rilevare i fronti del clock. Ad esempio, il fronte di salita del segnale clock può essere rilevato in molti casi (vedi osservazione pagine successive) mediante: if (clock’event) and (clock = ‘1’) S’last_value: un segnale che assume il valore precedentemente assunto dal segnale analizzato Molti altri attributi qui non analizzati

Caso di studio: Flip-Flop D Prendiamo in esame il Flip-Flop D (FFD). FFD D D Q Q CK CK Q* QN FFD: RSA che assume il valore logico presente su D durante i fronti di salita (positive edge triggered) dell’ingresso CK CK D Q

entity FFD_1 is Port ( D : in bit; CK : in bit; Q : out bit; QN : out bit); end FFD_1; architecture Behavioral of FFD_1 is begin processo: process(CK,D) if (CK'event) and (CK='1') then Q <= D; QN <= not(D); -- non potevo mettere QN <= not(Q) !!!!!! -- altrimenti NON contemporaneità end if; end process processo; end Behavioral; Mediante: “if (CK'event) and (CK='1')” è possibile determinare i fronti del clock quando si verifica un evento su CK e il livello del segnale è 1 (CK=1). Attenzione però; se il segnale di clock non fosse di tipo bit ma (ad esempio) di tipo STD_LOGIC la condizione sarebbe verificata anche se il clock passa da ‘X’ a ‘1!!

Nel caso esaminato; era proprio necessario inserire D nella sensitivity list del processo ? No, poteva essere omesso in quanto l’assegnamento ai segnali Q e QN è subordinato solo al fronte di salita del clock. Codice e simulazione escludendo D dalla sensitivity list del processo sono mostrati nel lucido successivo.

FFD escludendo D dalla sensitivity list entity FFD_1 is Port ( D : in bit; CK : in bit; Q : out bit; QN : out bit); end FFD_1; architecture Behavioral of FFD_1 is begin processo: process(CK) if (CK'event) and (CK='1') then Q <= D; QN <= not(D); end if; end process processo; end Behavioral; FFD2

FFD con comandi asincroni di set e reset Vogliamo dotare il FFD di comandi di “set” e “reset” asincroni (denominati rispettivamente, A_SET e A_RES). A_SET FFD A_SET D D Q Q CK CK Q* QN A_RES A_RES I comandi asincroni A_SET e A_RES sono prioritari rispetto agli altri ingressi La contemporanea attivazione dei due segnali è priva di significato dal punto di vista logico Nonostante questo, vogliamo modellare il FFD in modo che A_RES sia più prioritario di A_SET

entity FFD_comandi_asincroni is Port ( CK : in bit; D : in bit; A_SET : in bit; A_RES : in bit; Q : out bit; QN : out bit); end FFD_comandi_asincroni; architecture Behavioral of FFD_comandi_asincroni is begin processo: process(CK,A_SET , A_RES) -- comandi sincroni in logica positiva if (A_RES='1') then Q <='0'; QN <='1'; elsif (A_SET = '1') then Q <='1'; QN <='0'; elsif (CK='1') and (CK'event) then Q <= D; QN <= not(D); end if; end process processo; end Behavioral;

Reset asincrono (A_RES=1, A_SET=0) Set asincrono (A_RES=0, A_SET=1) Comandi asincroni entrambi asseriti (A_RES=1, A_SET=1): reset asincrono prioritario Set asincrono (A_RES=0, A_SET=1) Attenzione: comandi asincroni in logica positiva !

Approfondimento su segnali e variabili Progettare in VHDL una rete che periodicamente dopo tre periodi di clock setta al livello logico 1 la propria uscita per un periodo clock. La rete è dotata anche di un ingresso di reset (a_res). ? OUT OUT CK a_res CK OUT (0) (1) (2) (3) (0) (1) (2) (3)

use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; Andiamo ora ad analizzare alcune possibili realizzazioni, nelle quali vogliano anche analizzare lo stato interno. La entity per, per tutte, risulta: library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; use ieee.numeric_std.all; library unisim; use unisim.vcomponents.all ---------------------------------------------------------------------------------- -- Attenzione: per potere usare la somma fra vettori inserire tutti gli "use" -- indicati ntity Esercizio_3 is Port ( ck : in std_logic; a_res : in std_logic; ----------------------------------------------------------------------------- -- Portiamo all'esterno lo stato interno al fine di analizzarlo -- Molto spesso lo si fa anche per problemi di test stato_interno_counter : out std_logic_vector(1 downto 0); signal_out : out std_logic ); end Esercizio_3; Nei primi due casi la rete sarà modellata da due processi: un processo che gestisce l’aggiornamento dello stato del contatore: processo_contatore: process(ck,a_res) e un processo che genera l’uscita della rete: processo_uscita: process(stato_interno_signal)

Soluzione 1: segnali per lo stato interno In questa soluzione si adottano dei segnali per gestire lo stato del contatore. architecture Behavioral_1 of Esercizio_3 is -- definizione di un segnale di stato interno -- (un segnale out - stato_interno_counter - NON si può leggere) signal stato_interno_signal: std_logic_vector(1 downto 0); begin processo_contatore: process(ck,a_res) if (a_res='1') then stato_interno_signal <= "00"; -- per qualunque variazione di a-res o ck elsif (ck'event) and (ck='1') then stato_interno_signal <= stato_interno_signal + 1; -- NB operatore di somma -- librerie end if; -- altrimenti stato immutato -- esporta lo stato all'esterno stato_interno_counter <= stato_interno_signal; end process processo_contatore; -------------------------------------------------------------------------------------------------------------------------- processo_uscita: process(stato_interno_signal) if (stato_interno_signal="11") then signal_out<='1'; else signal_out <= '0'; end if; end process processo_uscita; end Behavioral_1;

La simulazione evidenzia un primo problema: Stiamo utlizzando vettori di tipo STD_LOGIC per lo stato interno. Ma lo stato è inizializzato solo quando si verifica il primo reset (che in questo caso, in accordo alle specifiche, non dipende dal clock). La soluzione consiste nell’inizializzare lo stato. architecture Behavioral_1 of Esercizio_3 is signal stato_interno_signal: std_logic_vector(1 downto 0):=“00”; -- attribuzione di un valore iniziale

La simulazione evidenzia anche un secondo problema: La stato si modifica sui fronti di discesa (!?) mentre l’uscita è corretta, sebbene in anticipo di ½ periodo di clock sullo stato (?!?). Perché ? Andiamo a rivedere il codice... architecture Behavioral_1 of Esercizio_3 is -- definisco un segnale di stato interno signal stato_interno_signal: std_logic_vector(1 downto 0):=“00”; begin processo_contatore: process(ck,a_res) if (a_res='1') then stato_interno_signal <= "00"; 1/2

elsif (CK'event) and (CK='1') then stato_interno_signal <= stato_interno_signal + 1; -- NB è stata usata -- una libreria qui !! end if; -- esporta lo stato all'esterno stato_interno_counter <= stato_interno_signal; -- è il vecchio valore di stato_interno_signal !!!! -- Il nuovo valore verrà aggiornato quando questo processo -- sarà risvegliato sul prossimo evento di un segnale -- presente nella sensitivity list, ovvero (escludendo A_RES) -- quando si avrà il prossimo evento sul clock... -- ...ma il prossimo evento sul clock è il fronte di discesa !!! -- Pertanto, quando si verifica il fronte di discesa -- (sempre nell'ipotesi di a_res non asserito) i due if sopra non -- saranno verificati e finalmente al SEGNALE stato_interno_counter -- sarà assegnato il valore + 1 !! end process processo_contatore; processo_uscita: process(stato_interno_signal) begin -- questo processo viene risvegliato quando il valore di -- stato_interno_signal (NON stato_interno_counter ) -- viene aggiornato, ovvero quando si -- esce dal processo precedente !! -- pertanto qui tutto funziona “regolarmente” !!! if (stato_interno_signal="11") then signal_out<='1'; else signal_out <= '0'; end process processo_uscita; end Behavioral_1; 2/2

Soluzione 2: segnali per lo stato interno Evitiamo di aggiornare il segnale prima di uscire dal processo (come avveniva nel caso precedente...) architecture behavioral_2 of esercizio_3 is -- definisco un segnale di stato interno signal stato_interno_signal: std_logic_vector(1 downto 0):="00"; begin processo_contatore: process(ck,a_res) if (a_res='1') then stato_interno_signal <= "00"; stato_interno_counter <= "00"; elsif (ck'event) and (ck='1') then stato_interno_signal <= stato_interno_signal + 1; -- esporta lo stato all'esterno stato_interno_counter <= stato_interno_signal; end if; end process processo_contatore; processo_uscita: process(stato_interno_signal) -- questo processo viene risvegliato quando il valore di -- stato_interno_signal viene aggiornato if (stato_interno_signal="11") then signal_out<='1'; else signal_out <= '0'; end process processo_uscita; end behavioral_2;

L’aggiornamento del segnale stato_interno_signal è subordinato al verificarsi dell’evento (CK'event) and (CK='1‘) consente di evitare il cambiamento di stato interno sui fronti di discesa del clock. Nonostante questo, lo stato interno viene aggiornato con un ritardo pari a 1 periodo di clock (come si evidenzia dal fatto che nella simulazione il segnale di uscita è 1 in corrispondenza dello stato 10) Perche ? Andiamo ad analizzare il codice...

architecture behavioral_2 of esercizio_3 is -- definisco un segnale di stato interno signal stato_interno_signal: std_logic_vector(1 downto 0):="00"; begin processo_contatore: process(ck,a_res) if (a_res='1') then stato_interno_signal <= "00"; stato_interno_counter <= "00"; elsif (ck'event) and (ck='1') then stato_interno_signal <= stato_interno_signal + 1; -- esporta lo stato all'esterno il “vecchio” -- valore di stato_interno_signal !!!! -- il segnale verrà aggiornato solo al prossimo -- fronte positivo del clock !! stato_interno_counter <= stato_interno_signal; -- -- lo stato interno del contatore è in ritardo di un clock rispetto a stato_interno_signal end if; end process processo_contatore; processo_uscita: process(stato_interno_signal) -- questo processo viene risvegliato quando il valore di -- stato_interno_signal viene aggiornato, ovvero quando si -- esce dal processo precedente !! -- pertanto qui tutto funziona regolarmente !!! if (stato_interno_signal="11") then signal_out<='1'; else signal_out <= '0'; end process processo_uscita; end behavioral_2;

Soluzione 3 (direttorio Esercizio3) – soluzione più diretta library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; use ieee.numeric_std.all; library unisim; use unisim.vcomponents.all; entity Esercizio_3 is Port (ck : in std_logic; a_res : in std_logic; stato_counter : inout std_logic_vector(1 downto 0); signal_out : out std_logic ); end Esercizio_3; architecture behavioral_3 of esercizio_3 is Begin processo_contatore: process(ck,a_res) is begin if (ck'event) and (ck='1') then if (a_res='1') then stato_counter <= "00"; signal_out <= '0'; else stato_counter <= stato_counter + 1; if (stato_counter = "10“ ) then signal_out<='1'; --N.B. al prossimo clock il contatore si porta a 11 e quindi l’uscita deve essere asserita else signal_out <= '0'; end if; end process processo_contatore; end behavioral_3;

La simulazione mostra che lo stato interno e l’uscita sono sincronizzati. Alla luce di queste osservazioni possiamo progettare un contatore modulo N con N qualsiasi indicato come valore di ingresso

Contatore modulo N con reset sincrono (direttorio Counter_N) Con gli strumenti che abbiamo a disposizione possiamo progettare con poche istruzioni un contatore modulo N programmabile e dotato di comando di reset sincrono A_RES, ENABLE. Il contatore è dotato anche di una uscita END_COUNT che comunica all’esterno il raggiungimento della base di conteggio. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; USE ieee.numeric_std.ALL; library UNISIM; use UNISIM.VComponents.all; entity Counter_modulo_N is Port (CK : in std_logic; A_RES : in std_logic; ENABLE : in std_logic; Max_val : in std_logic_vector (15 downto 0); COUNT : inout std_logic_vector (15 downto 0); END_COUNT : out std_logic); end Counter_modulo_N; architecture Behavioral of Counter_modulo_N is begin processo: process(CK, A_RES, ENABLE) if (CK='1') and (CK'event) then if (A_RES='1') then COUNT <= X"0000"; -- Rappresentazione esadecimale !!! END_COUNT <= '0'; ; -- Qui al prossimo clock si va a 0 elsif ENABLE='1' then if COUNT < Max_val then COUNT <= COUNT +1 else COUNT <= X"0000"; end if; if COUNT = Max_val -1 then END_COUNT <= '1'; -- Si attiva al prossimo clock !!!! else END_COUNT <= '0'; end process processo; end Behavioral;

Testbed 1/2 library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; USE ieee.numeric_std.ALL; library UNISIM; use UNISIM.VComponents.all; ENTITY Test IS END Test; ARCHITECTURE behavior OF Test IS COMPONENT Counter_modulo_N PORT( CK : IN std_logic; A_RES : IN std_logic; ENABLE : IN std_logic; Max_val : IN std_logic_vector(15 downto 0); COUNT : INOUT std_logic_vector(15 downto 0); END_COUNT : OUT std_logic ); END COMPONENT; signal CK : std_logic := '0'; signal A_RES : std_logic := '0'; signal ENABLE : std_logic := '0'; signal Max_val : std_logic_vector(15 downto 0) := (others => '0'); signal COUNT : std_logic_vector(15 downto 0); signal END_COUNT : std_logic; constant CK_period : time := 10 ns; BEGIN uut: Counter_modulo_N PORT MAP ( CK => CK, A_RES => A_RES, ENABLE => ENABLE, Max_val => Max_val, COUNT => COUNT, END_COUNT => END_COUNT )

Testbed 2/2 clock_process :process variable I: integer; begin A_RES <= '1'; Max_val <= X"0007"; -- contare fino a 7 for I in 3 downto 0 loop ck <= '0'; wait for ck_period/2; ck <= '1'; end loop; A_RES <= '0'; ENABLE <= '1'; ENABLE <= '0'; for I in 1 downto 0 loop for I in 0 to 40 loop wait; end process; END;

In questa simulazione (che è quella presente nelle esercizio) il valore impostato di conteggio è 7. Nella simulazione la “radice” con cui sono rappresentati i numeri è esadecimale

Attributi degli array Statement others Ovviamente in VHDL sono definiti degli attributi anche per gli array. Ad esempio, dato un vettore di tipo T VECTOR: std_logic_vector(4 downto 0); VECTOR’length ritorna il valore 5 Statement others Mediante others è possibile settare il contenuto di alcuni o di tutti gli elementi di in vettore che non sono esplitamene settati. Ad esempio, se vector è un vettore, vector <= (0=>'1', others =>'0'); setta il bit meno significativo a 1 e tutti gli altri bit al livello logico 0 (quanti ? Con others non è necessario saperlo) .

Funzioni di conversione Nelle librerie IEEE sono definite delle funzioni per la conversione Ad esempio in IEEE.std_logic_arith è definita la funzione di conversione da integer a STD_LOGIC_VECTOR (e molte altre funzioni di conversione) <slv_sig> = CONV_STD_LOGIC_VECTOR(<int_sig>, <int_size>); Ad esempio, se half_word è un segnale di tipo tipo STD_LOGIC_VECTOR(15 downto 0) e value è di tipo integer, la conversione di value a STD_LOGIC_VECTOR si ottiene mediante: half_word = CONV_STD_LOGIC_VECTOR(value, 16); In ISE le funzioni si trovano clikkando sulla icona . Con lo stesso comando è possibile accedere a dei “componenti” precompilati. V. la funzione “component”.

FFD predefinito -- FDCPE : In order to incorporate this function into the design, -- VHDL : the following instance declaration needs to be placed -- instance : in the architecture body of the design code. The -- declaration : instance name (FDCPE_inst) and/or the port declarations -- code : after the "=>" assignment maybe changed to properly -- : connect this function to the design. All inputs must be -- : connected. -- Library : In addition to adding the instance declaration, a use -- declaration : statement for the UNISIM.vcomponents library needs to be -- for : added before the entity declaration. This library -- Xilinx : contains the component declarations for all Xilinx -- primitives : primitives and points to the models that will be used -- : for simulation. -- Copy the following two statements and paste them before the -- Entity declaration, unless they already exist. Library UNISIM; use UNISIM.vcomponents.all; -- <-----Cut code below this line and paste into the architecture body----> -- FDCPE: Single Data Rate D Flip-Flop with Asynchronous Clear, Set and Clock Enable (posedge clk). -- Spartan-3E -- Xilinx HDL Language Template, version 12.1 FDCPE_inst : FDCPE -- I segnali corrispondenti debbono essere stati definiti nell’architecture generic map ( INIT => '0') -- Initial value of register ('0' or '1') port map ( Q => Q, -- Data output C => C, -- Clock input CE => CE, -- Clock enable input CLR => CLR, -- Asynchronous clear input D => D, -- Data input PRE => PRE -- Asynchronous set input ); -- End of FDCPE_inst instantiation

Cassaforte asincrona versione 1 (1/2) library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; library UNISIM; use UNISIM.VComponents.all; -- Il sistema riconosce la sequenza ASINCRONA 00-01-11 entity CassaAsincrona is Port ( X : in STD_LOGIC_VECTOR (1 downto 0); Reset : in STD_LOGIC; status : out STD_LOGIC_VECTOR (1 downto 0); Z : out STD_LOGIC); end CassaAsincrona; architecture Behavioral of CassaAsincrona is signal internal_status : STD_LOGIC_VECTOR (1 downto 0); begin sequence: process(X,Reset,internal_status) constant arrivato_00 : STD_LOGIC_VECTOR := "00"; constant arrivato_01 : STD_LOGIC_VECTOR := "01"; constant arrivato_11 : STD_LOGIC_VECTOR := "11"; constant idl : STD_LOGIC_VECTOR := "10";

In blu il corpo del programma Cassaforte asincrona versione 1 (2/2) begin if Reset = '1' then internal_status <= idle; status <= internal_status; Z <= '0'; else case internal_status is when idle => if X="00" then internal_status <= arrivato_00; end if; when arrivato_00 => if X="01" then internal_status <= arrivato_01; elsif X="00" then when arrivato_01 => if X="11" then internal_status <= arrivato_11; Z <= '1'; when others => -- ovvero status = arrivato_11 Z <= '0‘; end case; end process sequence; end Behavioral; In blu il corpo del programma

Cassaforte asincrona testbench (1/2) -------------------------------------------------------------------------------- -- Company: DEIS -- Engineer: G.Neri -- -- Create Date: 15:35:29 05/07/2010 -- Design Name: -- Module Name: Q:/Home/Key Disk/Studenti/Reti Logiche/Xilinx projects/CassaforteAsincrona/ProvaAsincrona.vhd -- Project Name: CassaforteAsincrona -- Target Device: -- Tool versions: -- Description: -- VHDL Test Bench Created by ISE for module: CassaAsincrona -- Dependencies: -- Revision: -- Revision 0.01 - File Created -- Additional Comments: -- Notes: -- This testbench has been automatically generated using types std_logic and -- std_logic_vector for the ports of the unit under test. Xilinx recommends -- that these types always be used for the top-level I/O of a design in order -- to guarantee that the testbench will bind correctly to the post-implementation -- simulation model. LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_unsigned.all; USE ieee.numeric_std.ALL; ENTITY ProvaAsincrona IS END ProvaAsincrona; ARCHITECTURE behavior OF ProvaAsincrona IS -- Component Declaration for the Unit Under Test (UUT) COMPONENT CassaAsincrona PORT( X : IN std_logic_vector(1 downto 0); Reset : IN std_logic; status : OUT std_logic_vector(1 downto 0); Z : OUT std_logic ); END COMPONENT;

Cassaforte asincrona testbench (2/2) --Inputs segnali interni signal X : std_logic_vector(1 downto 0) := (others => '0'); signal Reset : std_logic := '0'; --Outputs seggale interno signal Z : std_logic; signal status : std_logic_vector(1 downto 0); BEGIN -- Instantiate the Unit Under Test (UUT) uut: CassaAsincrona PORT MAP ( X => X, Reset => Reset, status => status, Z => Z ); -- Stimulus process stim_proc: process begin Reset <= '1'; -- hold reset state for 100 ns. Reset <= '0'; wait for 100 ns; X <= "10" ; wait for 10 ns; X <= "11" ; X <= "00" ; X <= "01" ; wait; -- forever end process; END;

Il sistema non funziona: perché ? – Rivedere il codice Simulazione Il sistema non funziona: perché ? – Rivedere il codice (Perché il processo si attiva al cambiamento di X ma anche dello stato e quindi quando lo stato diventa 11 immediatamente si ha una nuova attivazione del processo e lo stato si porta in 10)

Cassaforte asincrona versione 2 (1/2) ---------------------------------------------------------------------------------- -- Company: DEIS -- Engineer: G.Neru -- -- Create Date: 14:10:14 05/07/2010 -- Design Name: -- Module Name: CassaAsincrona - Behavioral -- Project Name: -- Target Devices: -- Tool versions: -- Description: -- Dependencies: -- Revision: -- Revision 0.01 - File Created -- Additional Comments: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; library UNISIM; use UNISIM.VComponents.all; -- Il sistema riconosce la sequenza ASINCRONA 00-01-11 entity CassaAsincrona is Port ( X : in STD_LOGIC_VECTOR (1 downto 0); Reset : in STD_LOGIC; status : out STD_LOGIC_VECTOR (1 downto 0); Z : out STD_LOGIC); end CassaAsincrona; architecture Behavioral of CassaAsincrona is signal internal_status : STD_LOGIC_VECTOR (1 downto 0):= "00"; signal previous_X : STD_LOGIC_VECTOR (1 downto 0):= "01"; begin sequence: process(X,previous_X, Reset,internal_status) is constant arrivato_00 : STD_LOGIC_VECTOR := "00"; constant arrivato_01 : STD_LOGIC_VECTOR := "01"; constant arrivato_11 : STD_LOGIC_VECTOR := "11"; constant idle : STD_LOGIC_VECTOR := "10";

In blu il corpo del programma begin if Reset = '1' then internal_status <= idle; status <= internal_status; Z <= '0'; previous_X <= X; else if X/=previous_X then case internal_status is when idle => -- 10 if X="00" then internal_status <= arrivato_00; end if; when arrivato_00 => if X="01" then internal_status <= arrivato_01; elsif X="00" then when arrivato_01 => if X="11" then internal_status <= arrivato_11; Z <= '1'; Z <= '0‘; when others => -- ovvero status = arrivato_11 end case; end process sequence; end Behavioral; Cassaforte asincrona versione 2 (2/2) In blu il corpo del programma

Processo !! E lo stato cambia quando solo se cambia l’ingresso !! Simulazione (con lo stesso testbench) Ora funziona perché ? Processo !! E lo stato cambia quando solo se cambia l’ingresso !!

Esercizi Sintetizzare in VHDL i progetti Altera precedentemente eseguiti con schematic diagram e gli esercizi di reti sincrone e asincrone proposti Progettare uno shiftt register a 8 bit con due suoi stadi retroazionati con operatore modulo che alterna ogni 55 clock la coppia di FF che alimentano l’EX_OR e che è protetto contro lo stato stabile con tutti 0 Progettare una rete sincrona che in funzione di tre bit di ingresso si comporta come un contatore avanti binario per 64 un contatore indietro binario per 64 uno shift register a destra uno shift register a sinistra un contatore avanti dei soli numeri pari (a partire da tutti 0) un contatore indietro dei soli numeri dispari (a partire da tutti 1) per tutte le altre configurazioni di ingresso permane la modalità di funzionamento precedentemente impostata

P.J. Ashenden “ The designer’s guide to VHDL – Third edition”- Morgan Kaufman - Elsevier – 2008 – ISBN 978-0-12-088785-9 P.P.Chu “FPGA prototyping by VHDL examples” – John Wiley & Sons – 2008 - ISBN 978-0-470-18531-5 M. Zwolinski “VHDL–Progetto di sistemi digitali” - Pearson–Prentice/Hall If we hear, we forget; if we see, we remember; if we do, we understand