FPGA: Approfondiamo la Metastabilità

Abbiamo visto nel precedente articolo cos’è la metastabilità e come minimizzare la sua propagazione tramite una catena di registri di sincronizzazione sotto riportata per comodità di lettura:

I flip-flop realizzano la asserzione asincrona / de-asserzione sincrona.

Un eventuale reset asincrono che viola i tempi di recovery e removal potrà però causare metastabilità nel primo flip-flop provocandone l’uscita q0 ad un valore intermedio tra 1 o 0 e assestandosi poi ad un valore logico casuale.

Se l’ingresso asincrono (il segnale reset) rimane però stabile, al successivo fronte di salita del clock q0 assumerà il valore dell’ingresso e al periodo di clock successivo sarà propagato all’uscita sync_reset.

Se la metastabilità non si risolve prima del fronte di clock successivo potrebbe propagarsi nel secondo flip-flop (quindi all’uscita), la probabilità è però minore tanto minore è la frequenza del clock.

La soluzione circuitale è pertanto valida se il segnale asincrono è sovra-campionato dai flip-flop prima di una sua variazione ed è ammissibile un ritardo nel segnale di uscita non costante.

Ipotizzando un ingresso che non causi metastabilità per semplicità il segnale di uscita (sync_reset) avrà un ritardo di 2 periodi di clock per passare da 0 a 1 mentre solamente un ritardo legato al tempo di reset asincrono del flip-flop nel passare da 1 a 0. Per questo si dice che realizzano la asserzione asincrona / de-asserzione sincrona.

E’ da notare dalla simulazione che se il segnale reset sarà indeterminato l’uscita assumerà il valore 1 logico sempre dopo 2 periodi di clock.

Il sovra-campionamento è necessario in quanto se il segnale reset cambiasse prima del fronte di clock successivo e tornasse quindi a 0 e la metastabilità si risolvesse con il solito valore (valore precedente), il valore del segnale reset non sarebbe mai presentato in uscita.

Il circuito visto non è quindi sempre applicabile in qualunque situazione ed è di fondamentale importanza la stabilità del valore di ingresso rispetto al periodo del clock, è però adatto per gestire l’ingresso proveniente da un segnale di reset filtrato preventivamente da anti-rimbalzo (debounced) come sulla scheda DE0-Nano.

La probabilità di propagazione ai successivi flip-flop e quindi all’uscita della metastabilità è calcolabili in termini di MTBF (Mean Time Between Failures), tempo medio tra guasti dovuti alla metastabilità, che Quartus ci permette di calcolare agevolmente.

La formula utilizzata è la seguente:

con C1 e C2 costanti dipendenti dal dispositivo (es. processo produttivo) e dalle operazioni operative (es. temperatura), fCLK è la frequenza del clock utilizzato per ricevere il segnale asincrono, fDATA la frequenza del segnale asincrono in ingresso. tMET è il tempo a disposizione del segnale per risolvere la metastabilità.

La formula ci indica che possiamo esponenzialmente migliorare la situazione aumentando il tMET e linearmente riducendo fCLK o fDATA.

Specifichiamo tramite un file SDC (mostrato sotto) la frequenza del nostro clock (fCLK nella formula)

Abilitiamo l’analisi della metastabilità tramite il menù  Assignments / Settings ed impostando Synchronizer identification a Forced If Asynchronous, di default Quartus è abbastanza conservativo e l’identificazione è disattivata

Apriamo adesso Assignments / Assignment Editor ed impostiamo per l’analisi l’analogo di fDATA nella formula, ovvero la frequenza del segnale di ingresso. Aggiungiamo una nuova voce scegliendo To *, Assignment Name Synchronizer Toggle Rate ed impostiamola a 50 milioni per simulare un ingresso commutante a 50 MHz. Questo valore può risultare eccessivo per un segnale di reset ma ci porrà sul lato sicuro e permetterà di mostrare le differenze di MTFB altrimenti non percettibili.

Avviamo adesso una compilazione completa del design ed apriamo il Metastability Report sotto la cartella TimeQuest Timing Analyzer del report della compilazione.

Notiamo che con un clock di 50 MHz il MTBF tipico stimato è di oltre 1 miliardo di anni, un risultato niente male.

Il tMET si può leggere dalla quarta riga è di 19.246 ns, molto elevato e comporta robustezza al nostro design.

Aumentando il clock a 400 MHz e ricompilando il MTBF si riduce notevolmente a 28.3 anni, la nuova constraints con le impostazioni di default del fitter non è soddisfabile è genera dei Warning Timing requirements not met durante la compilazione, il tutto comporterà fragilità nel design

Il tempo di assestamento disponibile in questo caso notiamo essere di 1.439 ns, molto inferiore al caso precedente.

E’ possibile notare come modificando i parametri del progetto per una sintesi più aggressiva ed utilizzando Design Space Explorer di cui abbiamo parlato in un articolo precedente, ci si avvicini maggiormente a soddisfare la frequenza di 400 MHz (ancora senza soddisfarla in questo caso) ed il MTBF cambi sensibilmente passando a 39.700 anni, una variazione di soli 0.305 ns pari a circa il 21% del valore precedente nell’ Avaible Settling Time comporta dunque una situazione molto diversa come era intuibile dalla formula dell’MTBF.

Altera consiglia di utilizzare un minimo di tre flip-flop per sincronizzare segnali asincroni proprio perché il tempo di assestamento è uno strumento fondamentale per evitare la metastabilità.

FPGA: Linee guida e Design Assistant, analizziamo un caso di metastabilità

Per migliorare l’affidabilità, le prestazioni e l’utilizzo delle risorse logiche nei nostri design, bisogna praticare una buona metodologia e capire come evitare le violazioni delle regole o linee guida raccomandate da Altera o comunque dal produttore del nostro dispositivo.

Quartus ci offre lo strumento Design Assistant per controllare la violazione delle regole e l’aderenza del nostro progetto alle linee guida di Altera.

Dopo aver compilato il nostro progetto HelloHw sviluppato negli articoli precedenti ed arricchito con un testbench scegliamo dal menù Processing / Start il comando Start Design Assistant.

Comparirà tra i Report la cartella Design Assistant contenente le violazioni del nostro progetto, scegliendo Medium Violations notiamo che non viene rispettata una regola di media criticità mentre scegliendo Information only Violations notiamo diverse violazioni più che altro informative relative al fan-out che non presentano però criticità.

La violazione di media criticità come mostrato dal report è relativa alla regola:

Rule R102: External reset signals should be synchronized using two cascaded registers

Incontriamo questo problema perché la nostra entità HelloHw prevedeva un segnale di ingresso reset gestito in modo asincrono rispetto al segnale clock e mappato direttamente ad un pin esterno della FPGA.

Questa situazione può però portare ad un problema di metastabilità se il reset, che può avvenire in qualsiasi momento in quanto il pin esterno è collegato ad un pulsante, avviene violando il setup o l’hold time dei flip-flop collegati al reset. Nel caso di porte asincrone (es. reset asincrono del flip-flop) questi tempi vengono più propriamenti chiamati recovery e removal time.

La probabilità di metastabilità non è in questo caso elevatissima, vedremo come calcolarla successivamente, per questo nell’introduzione a Quartus per non complicare l’esempio non è stata inizialmente presa in considerazione. Per un design affidabile è bene però affrontare questo argomento.

I flip-flop seppur non definiti esplicitamente vengono generati per realizzare il registro del contatore, sotto è riportata la vista RTL del circuito come visto in un articolo precedente.

La metastabilità può essere pensata come uno stato incerto che dopo un certo periodo di tempo detto tempo di risoluzione dove l’uscita può oscillare, si stabilizza ad un valore casuale. Una situazione non desiderata che può portare a problemi ed errori nei nostri design. L’incertezza può essere pensata come ad uno stato instabile, un palla nella cima di una collina molto ripida che alla minima perturbazione può andare casualmente al vecchio valore o ad un nuovo valore (quindi 0 o 1)

Sotto un esempio di metastabilità, l’ingresso viola il recovery time cambiando il proprio valore troppo vicino al fronte di salita del clock e comporta un uscita metastabile ovvero un valore elettrico intermedio tra i valori relativi ai due stati logici che può risolversi successivamente nel valore logico 1 o 0.

Il Design Assistant ci avverte quindi di una situazione pericolosa che a progettisti in erba può facilmente sfuggire, la soluzione al problema consiste, come suggerito dalla descrizione della violazione, nell’utilizzare due flip-flop in cascata per sincronizzare la de-asserzione del reset.

Esistono diverse implementazioni della soluzione con diversi vantaggi /svantaggi, vediamo con un esempio concreto una soluzione molto affidabile: l’asserzione asincrona / de-asserzione sincrona tramite il circuito:

In realtà la soluzione non risolve in termini assoluti il problema che nelle simulazioni verrà riportato a meno di non impostare tempi di recovery e removal time nulli, risolve però il problemi in termini probabilistici, la probabilità che il secondo flip-flop presenti un uscita metastabile che si propaga nel resto del circuito diventa molto bassa come vedremo maggiormente in dettaglio in un prossimo articolo. Ad ogni modo è utile sapere che è possibile aggiungere ulteriori flip-flop per rendere piccola a piacere la probabilità di metastabilità in uscita.

Il codice VHDL per realizzare un modulo di reset sincrono è presto fatto:

Dove q0 sarà il segnale interno di uscita del primo flip-flop D.

L’utilizzo del modulo sarà abbastanza semplice, basterà interporlo al segnale di reset proveniente dal mondo esterno alla FPGA per generare un segnale di reset sincrono come illustrato dal seguente schema a blocchi.

Così facendo la violazione scomparirà dal report.

Concludendo l’utilità del Design Assistant è molto elevata e seppur non risolva in automatico i problemi la loro consapevolezza è sempre il primo passo verso la risoluzione.

FPGA: Compilazione distribuita

Oltre ad utilizzare i diversi core di un singolo pc per la compilazione è possibile accelerare la lunga esplorazione dello spazio delle soluzioni con Design Space Explorer (DSE) tramite l’utilizzo di più computer

Una volta aperto Altera Design Space Explorer scegliamo dal menù Parallel DSE la voce Distribute Compilations to Other Machines se non spuntata, dopodiché scegliamo Configure Resources all’interno dello stesso menù.

Si aprirà una finestra che permetterà di aggiungere le macchine con cui vorremo dividere il carico di lavoro richiesto dalle compilazioni, scegliamo il pulsante Add ed inseriamo l’indirizzo IP concatenato alla porta (di default 1977) e scegliamo OK, apparirà nella lista. Ripetiamo l’operazione per ogni pc remoto. Chiudiamo adesso la finestra Configure Resources premendo OK.

NB: Nella documentazione non è esplicitato il formato indirizzo:porta con cui inserire il pc remoto e si potrebbe avere qualche frustrazione leggendo solamente la guida

Sulle macchine remote (nell’immagine solo il pc con IP 192.168.1.222) assicuriamoci che sia installata la stessa versione di Quartus e lanciamo dalla riga di comando “quartus_sh --qslave” dalla cartella bin di Quartus, in genere C:\altera\13.0\quartus\bin, apparirà il terminare Quartus II QSlave che rimarrà in attesa di pacchetti di lavoro da elaborare da parte del programma Design Space Explorer sul pc “master”

Di default il terminale svolgerà un solo lavoro in contemporanea, ma se la nostra macchina remota dispone di più core è possibile impostare il parametro jobslimit all’avvio del terminale QSlave, chiamando ad esempio il comando:

quartus_sh –qslave jobslimit=2

Il terminale riporterà in questo caso il messaggio: Slave can run 2 job(s) concurrently a conferma della corretta impostazione ricevuta, in modo analogo è possibile cambiare la porta tramite il parametro port.

NB: E’ necessario configurare il firewall ed il router per poter ricevere in ingresso i dati da elaborare

Tornando al pc master, lanciando la compilazione in Design Space Explorer dopo poco noteremo nel terminale alcuni startRemoteCommand, segno che la compilazione sta per essere avviata anche sugli altri computer remoti dove si popolerà il terminale QSlave di messaggi sulla stato della lavorazione.

Il tempo totale di compilazione potrà essere significativamente ridotto con un adeguato parco macchine, lo svantaggio è però sicuramente il maggiore consumo energetico.

FPGA: Alla scoperta dello spazio soluzioni del Fitter

Con l’aumentare delle risorse delle FPGA lo spazio delle soluzioni che deve affrontare il fitter cresce ad un ritmo incredibilmente veloce, ad esempio un dispositivo Cyclone IV EP4CE22 contiene 22.320 LEs (senza contare la memoria integrata, i blocchi M9K, etc..).

Se proviamo ad adattare un design di 1 solo registro (occupante quindi 1 LE) ci troviamo davanti 22.320 differenti soluzioni al problema. Un design di 2 soli registri aumenta questo numero a 22.320 x 22.319 = 498.160.080 soluzioni

Il fitter deve quindi esplorare rapidamente un grande numero di soluzioni per trovare un buon risultato, l’esplorazione completa è in generale non fattibile e questo aiuta a spiega perché una piccola modifica in una porzione del design causa risultati diversi sulle altre parti. Non appena il fitter esegue uno spostamento diverso, si ritroverà in un’area completamente diversa dello spazio soluzioni.

I criteri principali col quale il fitter determina la qualità delle soluzioni sono le prestazioni (slack) e la facilità di instradamento (routability).

Vediamo un esempio semplificato di uno spazio soluzioni con questi criteri:

Con questo enorme numero di soluzioni come fa il fitter a convergere ad una soluzione? Quartus II utilizza un algoritmo basato sul Simulated Annealing (http://it.wikipedia.org/wiki/Simulated_Annealing) che tra le origini da un’algoritmo utilizzato per simulare il raffreddamento dei metalli.

Come spiegazione semplificata inizialmente il fitter getta tutto nel dispositivo in posizioni legali che saranno completamente non instradabili e con tempistiche terribili. A questo punto la soluzione è estremamente ”calda” ed il fitter inizierà a muovere gli elementi intorno, sempre mantenendo posizioni legali, mentre la soluzione si “raffredda” ed il posizionamento migliora

La linea verde rappresenta i movimenti del fitter nello spazio soluzioni. Il fitter cerca costantemente una punto più basso nel grafico (soluzione migliore). Nell’immagine converge ad un punto di minimo locale seppur non il minimo globale. Lo spazio soluzioni è così esteso che è praticamente impossibile trovare il minimo assoluto.

Una nota, la linea verde si muove verso l’alto, il fitter accetta quindi risultati peggiori prima di procedere. Questa è un’interessante proprietà dell’algoritmo in quanto permette di uscire dai primi minimi locali trovati per cercare soluzioni migliori. Questa proprietà è anche chiamata temperatura

Un esempio pratico da una prospettiva di posizionamento sul dispositivo potrebbe essere un design ottimale nell’angolo basso a sinistra del chip ma inizialmente posizionato in alto a destra. Muovendo un singolo elemento in basso a sinistra, il risultato totale può essere peggiore, in quanto il nodo è sempre collegato con gli altri elementi in alto a destra. Ma a mano a mano che gli altri nodi saranno spostati in basso a sinistra il fitter sarà in grado di uscire dal minimo locale per arrivare a soluzioni migliori.

La temperatura determina quanto spesso il fitter accetta risultati peggiori, inizialmente, quando il dispositivo è caldo, il fitter accetta maggiormente risultati peggiori, quando il dispositivo si raffredda accetterà meno spesso questo tipo di risultati.

In Quartus è possibile modificare parte della temperatura tramite l’impostazione Placemente Effort Multiplier ed Router Effort Multiplier sotto il menu Assignments / Settings / Fitter Settings / More Settings.

Mano a mano che il valore viene incrementato il fitter procederà dal caldo al freddo più gradualmente, i tempi di compilazione però aumenteranno così come le possibilità di trovare soluzioni migliori.

Potenziali fonti di variazione nel fitting del progetto sono:
- Tutti i files di design es. VHDL, Schematici, EDIF, etc..
- Tutte le constraints nei file .sdc (il calcolo dei tempi per motivi di performance si basa su stime approssimative anziché sull’esecuzione completa di TimeQuest)
- Tutti gli assegnamenti nei file .qsf
- La versione di Quartus II
- Il sistema operativo
- Qualcosa che mi sono sicuramente scordato

La più piccola variazione (anche cambiare il nome di una rete nel design) può produrre risultati completamente diversi, ricompilando però i soliti file senza cambiare nessuna fonte di variazione si ottiene il solito risultato, per ottenere diversi risultati senza modifiche fittizie (che in realtà non servono) è possibile modificare il parametro Seed (letteralmente seme) del fitter

Non esiste però un valore migliore di un’altro per il Seed, uno strumento utile che ci può venire in aiuto per trovare la soluzione migliore è il Design Space Explorer accessibile tramite il menù Tools / Launch Design Space Explorer

E’ richiesta l’impostazione preventiva di constraints nel progetto, ad esempio delle frequenza di clock che si vuole ottenere. Tramite TimeQuest è disponibile un’interfaccia grafica per la creazione del file .sdc necessario

Design Space Explorer permette di provare diversi semi ed esplorare soluzioni diverse del fitter in maniera automatica mantenendo la migliore in base ai parametri impostati.

L’utilizzo del programma è molto intuitivo, semplicemente premendo il pulsante Explore Space (accessibile anche dal menù Processing) in un semplice design visto nei precedenti articoli si è potuto migliorare il periodo di clock massimo da 4.438 ns (225 MHz) a 2.54 ns (394 MHz) in circa 6 minuti, design complessi possono però richiedere tempi di calcolo molto elevati.

I calcoli vista la loro mole sono distribuibili su più processori in sistemi multi-core o su diverse macchine (in base alla licenza che si ha a disposizione).

Abbiamo in questo articolo visto un po’ di teoria e come sfruttare in pratica la varianza del fitter per cercare il risultato migliore tramite il tool Design Space Explorer, molto utile soprattutto quando i requisiti del progetto non sono soddisfatti per una manciata di picosecondi, qualche compilazione con variazione del seme porterà probabilmente al risultato sperato.

FPGA: Compilazione parallela gratuita con Quartus II v13

La versione gratuita di Quartus II v13, la Web Edition, ha funzionalità ridotte rispetto alla Subscription edition, versione completa a pagamento.

Alcune funzionalità tra cui la compilazione parallela sono sbloccabili abilitando l’invio di informazioni sull’utilizzo del programma ad Altera per per il miglioramento del programma stesso. In passato questa importante funzionalità era riservata alla versione a pagamento ma con la nuova versione Altera ha reso possibile abbreviare di molto i tempi di compilazione anche sulla versione gratuita.

E’ importante sapere che non saranno inviati i file sorgenti dei propri design ma solamente informazioni come i vincoli (es. i requisiti del clock), il device utilizzato, etc.. come è possibile leggere dal programma di abilitazione Quartus II TalkBack avviabile dal menù Start.

Una volta abilitato il TalkBack verifichiamo che a livello globale sia abilitata la compilazione parallela dal menù Tools / Options

E’ comunque possibile impostare ogni singolo progetto dal menù Assignments / Settings per sorpassare le impostazioni globali scegliendo quella più appropriata per il singolo progetto.

Per verificare l’utilizzo effettivo dei vari processori nella compilazione parallela, dai report è possibile scegliere la voce Parallel Compilation per diverse fasi di compilazione (Analysis & Synthesis, Fitter, TimeQuest, etc..)

Buona compilazione parallela a tutti

FPGA: I Testbench

 

Verificare manualmente i propri design creando le forme d’onda di stimolo in ModelSim può risultare un’operazione lunga e faticosa, soprattutto se è necessario ripetere più volte i test ad ogni modifica. Il transcript di ModelSim, una console che permette di inserire testualmente le azioni da eseguire, può alleviare il problema ma esiste un’alternativa migliore da utilizzare sistematicamente.

Nel paradigma di sviluppo software esiste il concetto di unit-test, un semplice programma il cui scopo è verificare se un componente si comporta come desiderato. Gli uni-test sono scritti manualmente dal programmatore e per verificare la correttezza di una funzione possono ad esempio presentare in ingresso alcuni dati e confrontare il risultato con dati noti.

Nel mondo della progettazione di sistemi elettronici digitali in VHDL esiste un concetto simile, il test-bench, un’entità VHDL non sintetizzabile ma eseguibile da un simulatore che si occupa di presentare degli stimoli di ingresso a delle entità ed eventualmente verificarne l’evoluzione delle uscite. Il linguaggio VHDL presenta un’ampia varietà di costrutti non sintetizzabili che ci potranno venire in aiuto nella stesura dei test.

Ecco un esempio di testbench per l’entità HelloHw creata nell’articolo precedente (con conteggio del contatore fino a 10 e non 50.000.000 per abbreviare i tempi di simulazione):

---

library IEEE;
use IEEE.std_logic_1164.all;

entity HelloHwTB is
end HelloHwTB;

architecture TBImpl of HelloHwTB is
    component HelloHw
        port
        (       
            clock    : in  STD_LOGIC;
            reset    : in  STD_LOGIC;               
            led        : buffer STD_LOGIC
        );
    end component;
    signal clock, reset, led: std_logic;   
begin

    uut: HelloHw port map(
        clock => clock,
        led => led,
        reset => reset
    );
   
    clock_proc: process
    begin
        clock <= '0';
        wait for 10 ns;
       
        clock <= '1';
        wait for 10 ns;
    end process;
   
    reset_proc: process
    begin
        reset <= '0';
        wait for 10 ns;
        reset <= '1';
        wait;
    end process;
   
    stim_proc: process
    begin        
        wait for 10 ns;
        assert led = '0';  -- after reset low output
        wait for 181 ns;
        assert led = '1';  -- after reset one cycle less (count to 9)
        wait for 200 ns;
        assert led = '0';
        wait for 200 ns;
        assert led = '1';
        wait;
    end process;
 
end TBImpl;

---

Il nostro testbench sarà sostanzialmente un’entità vuota chiamata HelloHwTB come è possibile vedere dalle prime righe di codice, l’implementazione istanzierà il componente HelloHw e creerà dei segnali da collegare (mappare) al componente tramite l’istruzione port map

Il test consisterà in tre processi eseguiti parallelamente:

- un processo clock_proc che avrà il compito di generare il clock (in questo caso 50 MHz)

- un processo reset_proc che inizialmente resetterà il componente e che poi resterà in attesa indefinitivamente

- un processo stim_proc che si occuperò di controllare le uscite dopo un certo periodo per verificare se corrispondenti ai valori desiderati, i primi 10 ns sono per attendere il reset del componente dopodiché si verificherà (in malo modo per semplicità) che assuma alternativamente i valori 0 ed 1 dopo. Da notare che il primo ciclo dopo il reset sarà più breve di 20ns.

Si notino le istruzioni wait for per attendere un intervallo temporale e l’istruzione assert per verificare una condizione logica e nel caso non fosse verificata generare un errore nel simulatore.

Per poter eseguire il test aggiungiamo un file VHDL al nostro progetto col codice del testbench sopra riportato

Scegliamo il menù Assignements / Settings, raggiungibile come evidenziato dall’immagine anche da barra degli strumenti ed arriviamo alla categoria EDA Tool Settings / Simulation dove sceglieremo come Compile test bench nella sezione NativeLink settings il nostro testbench premendo sul pulsante Test Benches. NativeLink è il sistema di scambio dati tra Quartus e programmi di terze parti,

Nell finestra che apparirà dovremmo ricordarci di impostare il periodo di simulazione a 1000 ns (o un tempo ragionevole) per evitare di simulare un periodo troppo lungo non utile alla verifica del componente. In alternativa sarebbe stato possibile modificare il testbench per fermare il clock dopo il periodo di test e scegliere la voce Run simulation until all vector stimuli are used

Dopo aver confermato compiliamo il nostro progetto (Analysis & Synthesis) ed eseguiamo la RTL Simulation, senza compiere ulteriori azioni una volta aperto ModelSim verranno simulati nel modo descritto i nostri segnali

Nella finestra Transcript non sarà presente nessun errore, segno che gli assert sono stati “onorati” e che il nostro design funziona come abbiamo “previsto”. Nel caso di errori messaggi come

# ** Error: Assertion violation.
#    Time: 190 ns  Iteration: 0  Instance: /hellohwtb

Ci informeranno in quale istanza ed istante si è verificata la violazione.

In casi semplici è sempre consigliato controllare manualmente le forme d’onda per identificare eventuali discrepanze dal risultato che si voleva ottenere. In situazioni più complicate è possibile leggere gli input dei test da dei file e registrare i risultati ottenuti.

FPGA: Introduzione a Quartus II e ModelSim

Una domanda spesso posta è: dove iniziare con le logiche programmabili come FPGA e CPLD?

Il prerequisito di base è senz’altro una buona conoscenza delle reti logiche e delle basi di elettronica, esistono diversi libri sull’argomento tra cui la quarta edizione del libro Reti Logiche 4/Ed di M. Morris Mano e Charles Kime tradotto in italiano da Pearson (non tratta però le basi di elettronica), l’esperienza con microcontrollori è un plus ma direi indispensabile quando si utilizzerà l’I/O delle FPGA in quanto molto delicato. Una errata impostazione o un cortocircuito anche temporaneo può irreparabilmente rendere inutilizzabile il nostro costoso chip.

Sulle FPGA esistono diversi libri, quasi tutti in inglese, che guidano nei primi passi e nello studio di linguaggi come VHDL o Verilog, tralasciano in genere l’utilizzo dei software di sviluppo come Quartus, ISE, etc.. a favore del linguaggio che è ormai standard e portabile da un’ambiente di sviluppo all’altro. E’ possibile trovare sulla rete delle dispense di corsi o seminari universitari ma spesso meno informative di un libro in quanto pensate per lezioni frontali.

Il datasheet è la fonte informativa principale per ogni circuito integrato, è sempre bene consultarlo per il proprio modello di FPGA.

Ogni produttore di dispositivi (come Altera, Xilinx, etc..) ha poi nel proprio sito un quantitativo più o meno imponente di Tutorial, Application Notes, Handbook e guide sull’utilizzo dei vari strumenti di sviluppo, spesso però iniziare con tale materiale può risultare difficile.

I forum specialistici ufficiali e non (es. alteraforum, delucagiovanni forum) rappresentano inoltre un’utile risorsa per chiarire i dubbi che possono sorgere e che è bene chiarire al più presto per iniziare col piede giusto ad utilizzare le logiche programmabili.

Vediamo in una videolezione come rompere il ghiaccio con programmi come Quartus II di Altera ed il simulatore ModelSim, argomenti che spesso i libri non toccano. Per una proficua visione è necessario sapere cos’è una FPGA ed avere un’idea del linguaggio VHDL, entrambi i software utilizzati sono scaricabili in versione gratuita dal sito Altera.

Con la scheda di sviluppo DE0-Nano (link produttore) creeremo e verificheremo un semplice “hardware su FPGA” che permetterà ad un led di lampeggiare, si potrà così avere un’idea di come utilizzare i tools di sviluppo per poter approfondire poi in autonomia le incredibili possibilità offerte da questi strumenti.

Introduzione alla progettazione con le FPGA: Quartus e ModelSim

Il codice esaminato nella videolezione (versione finale) occupante 56 LEs (Elementi Logici):

library ieee;
use ieee.std_logic_1164.all;
entity HelloHw is
  port
  (    
    clock  : in  STD_LOGIC;
    reset  : in  STD_LOGIC;        
    led  : buffer STD_LOGIC
  );
end HelloHw;
architecture HelloHwImpl of HelloHw is    
begin
  count : process(clock, led)
    variable counter : integer := 0;
  begin
    if(reset = '0') then
      counter := 0;
      led <= '0';
    else
      if(RISING_EDGE(clock)) then
        counter := counter + 1;
        if(counter = 50000000) then
          counter := 0; 
          led <= not led;
        end if;
      end if;
    end if;
  end process;
end HelloHwImpl;
 

E’ possibile inoltre visualizzare il circuito generato a livello RTL (Register transfer level) dal menù Tools / Netlist Viewers / RTL Viewer

Verrà visualizzato il seguente schema

Dove è visibile un MUX (Multiplexer), un registro da 32 bit, un sommatore ed un comparatore a 32 bit ed infine un flip flop D.

Per contare fino a 50.000.000 sono necessari però solamente 26 bit, con una piccola modifica al codice, specificando il range della variabile counter si otterrà un risultato molto migliore durante la sintesi

variable counter : integer range 0 to 50000000 := 0;

L’utilizzo delle risorse calerà da 56 a 48 LEs in quanto il circuito sarà sintetizzato con elementi da 26 bit al posto di 32 bit.

Per oggi è tutto, buono studio di logiche programmabili

PS: Il video NON mostra il flusso di sviluppo completo ma introduce solamente l’argomento. Una parte importante della progettazione è l’inserimento di vincoli temporali e la loro analisi assieme a quella dei consumi energetici.

Introduzione a Quartus II e ModelSim

Una domanda spesso posta è: dove iniziare con le logiche programmabili come FPGA e CPLD?

Il prerequisito di base è senz’altro una buona conoscenza delle reti logiche e delle basi di elettronica, esistono diversi libri sull’argomento tra cui la quarta edizione del libro Reti Logiche 4/Ed di M. Morris Mano e Charles Kime tradotto in italiano da Pearson (non tratta però le basi di elettronica), l’esperienza con microcontrollori è un plus ma direi indispensabile quando si utilizzerà l’I/O delle FPGA in quanto molto delicato. Una errata impostazione o un cortocircuito anche temporaneo può irreparabilmente rendere inutilizzabile il nostro costoso chip.

Sulle FPGA esistono diversi libri, quasi tutti in inglese, che guidano nei primi passi e nello studio di linguaggi come VHDL o Verilog, tralasciano in genere l’utilizzo dei software di sviluppo come Quartus, ISE, etc.. a favore del linguaggio che è ormai standard e portabile da un’ambiente di sviluppo all’altro. E’ possibile trovare sulla rete delle dispense di corsi o seminari universitari ma spesso meno informative di un libro in quanto pensate per lezioni frontali.

Il datasheet è la fonte informativa principale per ogni circuito integrato, è sempre bene consultarlo per il proprio modello di FPGA.

Ogni produttore di dispositivi (come Altera, Xilinx, etc..) ha poi nel proprio sito un quantitativo più o meno imponente di Tutorial, Application Notes, Handbook e guide sull’utilizzo dei vari strumenti di sviluppo, spesso però iniziare con tale materiale può risultare difficile.

I forum specialistici ufficiali e non (es. alteraforum, delucagiovanni forum) rappresentano inoltre un’utile risorsa per chiarire i dubbi che possono sorgere e che è bene chiarire al più presto per iniziare col piede giusto ad utilizzare le logiche programmabili.

Vediamo in una videolezione come rompere il ghiaccio con programmi come Quartus II di Altera ed il simulatore ModelSim, argomenti che spesso i libri non toccano. Per una proficua visione è necessario sapere cos’è una FPGA ed avere un’idea del linguaggio VHDL, entrambi i software utilizzati sono scaricabili in versione gratuita dal sito Altera.

Con la scheda di sviluppo DE0-Nano (link produttore) creeremo e verificheremo un semplice “hardware su FPGA” che permetterà ad un led di lampeggiare, si potrà così avere un’idea di come utilizzare i tools di sviluppo per poter approfondire poi in autonomia le incredibili possibilità offerte da questi strumenti.

[VIDEO IN PUBBLICAZIONE]

Il codice esaminato nella videolezione (versione finale) occupante 56 LEs (Elementi Logici):

library ieee;
use ieee.std_logic_1164.all;
entity HelloHw is
  port
  (    
    clock  : in  STD_LOGIC;
    reset  : in  STD_LOGIC;        
    led  : buffer STD_LOGIC
  );
end HelloHw;
architecture HelloHwImpl of HelloHw is    
begin
  count : process(clock, led)
    variable counter : integer := 0;
  begin
    if(reset = '0') then
      counter := 0;
      led <= '0';
    else
      if(RISING_EDGE(clock)) then
        counter := counter + 1;
        if(counter = 50000000) then
          counter := 0; 
          led <= not led;
        end if;
      end if;
    end if;
  end process;
end HelloHwImpl;
 

E’ possibile inoltre visualizzare il circuito generato a livello RTL (Register transfer level) dal menù Tools / Netlist Viewers / RTL Viewer

Verrà visualizzato il seguente schema

Dove è visibile un MUX (Multiplexer), un registro da 32 bit, un sommatore ed un comparatore a 32 bit ed infine un flip flop D.

Per contare fino a 50.000.000 sono necessari però solamente 26 bit, con una piccola modifica al codice, specificando il range della variabile counter si otterrà un risultato molto migliore durante la sintesi

variable counter : integer range 0 to 50000000 := 0;

L’utilizzo delle risorse calerà da 56 a 48 LEs in quanto il circuito sarà sintetizzato con elementi da 26 bit al posto di 32 bit.

Per oggi è tutto, buono studio di logiche programmabili

Introduzione ad ASF (quinta parte) - Il sistema di clock

Indice degli articoli su ASF

Scopriamo in questo articolo il flessibile sistema di clock dell’AVR XMega A4U che ricordiamo essere molto simile agli altri XMega e vediamo come configurarlo con semplicità grazie al modulo ASF System Clock Control che abbiamo aggiunto al nostro progetto ed analizzato nelle precedenti puntate.

Per chi volesse scaricare il progetto Atmel Studio creato fino ad ora: progetto_introduzione_ASF_3

Come detto nell’articolo precedente, dopo il reset (quindi all’avvio) il dispositivo partirà sempre dall’oscillatore interno da 2 MHz dopodiché sarà possibile cambiare a runtime attraverso il nostro firmware i vari clock di sistema.

Vediamo adesso uno schema tratto dal datasheet del microcontrollore che riassume bene cosa ci offre relativamente ai clock:

Inizialmente si può essere spaventati da tante opzioni e sigle, una domanda spesso posta dagli esordienti è “ma non bastava un semplice clock generale?”

Il microcontrollore dispone di molte periferiche che lavorano tipicamente a velocità diverse dalla CPU:

- il modulo Brown-out che rileva eventuali cali di alimentazione azionando il reset ed il Timer Watchdog che permette la rilevazione di blocchi del firmware lavorano ad 1 kHz generato a partire da un clock a 32 kHz

- il Contatore Real Time (RTC) che permette di tenere traccia del tempo lavora tipicamente a 1024 kHz ma può lavorare con maggiore risoluzione (maggiore di 1ms) a 32.768 kHz

- il modulo USB richiede un clock minimo di 6 MHz per lavorare in low speed ed almeno 48 MHz per la modalità full speed

- le periferiche come il controller DMA, il sistema di eventi, il controller delle interruzioni e la RAM hanno un clock impostabile chiamato clkPER

- il modulo EBI (External Bus Interface) usato per collegare memorie esterne come SRAM e SDRAM o periferiche come display LCD mappati in memoria lavora ad un clock clkPER2 veloce fino al doppio rispetto alle periferiche. Il modulo è presente solo su alcuni package, in generale con un elevato numero di pin, non è presente sulla nostra scheda di sviluppo EWS ATXMega32A4U.

- il modulo Hi-Res ha clock clkPER4 fino al quadruplo rispetto alle periferiche, è utilizzato per generare forme d’onda ad alta risoluzione

Adesso il perché il micro ha diversi clock configurabili può risultare più chiaro, in alcuni casi la scelta permetterà di privilegiare la velocità e la precisione in altri il risparmio energetico e minori possibilità di interferenze elettromagnetiche (EMI). Questa panoramica ci ha dato inoltre un’idea di cosa fanno alcune periferiche del micro.

I clock delle periferiche clkPER4, clkPER2, clkPER e della CPU e memoria EEPROM non volatile clkCPU sono generati a partire da clkSYS che è selezionato direttamente da una delle varie sorgenti di clock, dopodiché come è possibile vedere dal seguente schema può essere diviso diverse volte da vari Prescaler configurabili per generare le altre frequenze.

Dopo questa introduzione al sistema di clock comprendere il file di configurazione conf_clock.h (sotto riportato) del modulo ASF System Clock Control sarà senz’altro più semplice:

Tralasciamo per il momento le voci relative al PLL che vedremo in un prossimo articolo.

Impostiamo adesso come sorgente del clock di sistema (clkSYS) l’oscillatore esterno da 12 MHz presente sulla scheda, per fare ciò dobbiamo commentare la prima riga (o comunque le altre definizioni di CONFIG_SYSCLK_SOURCE) e de-commentare

#define CONFIG_SYSCLK_SOURCE        SYSCLK_SRC_XOSC

Per specificare la frequenza è necessario de-commentare

#define CONFIG_XOSC_RANGE XOSC_RANGE_12TO16

Se avessimo avuto un oscillatore non compreso tra 12 e 16 MHz avremmo dovuto scegliere la corrispondente definizione.

Possiamo notare che il Prescaler A ed il Prescaler B e C sono impostati ad 1 tramite le righe

#define CONFIG_SYSCLK_PSADIV          SYSCLK_PSADIV_1
#define CONFIG_SYSCLK_PSBCDIV         SYSCLK_PSBCDIV_1_1

In particolare la prima definizione si occupa di impostare il Prescaler A e la seconda i Prescaler B e C, questo poiché i Prescaler B e C sono dipendenti tra loro nella scelta dei valori di divisione.

Nel file di intestazione asf\common\services\clock\xmega\sysclk.h sono presenti i valori che possiamo assegnare alle due definizioni

Per raggiungere questo file ricordo che possiamo andare alla definizione ad esempio di SYSCLK_PSADIV_1 e tramite il comando Goto implementation accessibile tramite click destro sulla parola verrà aperto il file interessato che contiene le nostre definizioni.

Con questa configurazione il nostro micro, la cpu e tutte le sue periferiche, viaggeranno a 12 MHz.

Impostando invece ad esempio

#define CONFIG_SYSCLK_PSBCDIV         SYSCLK_PSBCDIV_4_1

Avremmo avuto il Prescaler B a 4 e gli altri ad 1 avendo così: clkSYS e clkPER4 a 12 MHz ma clkPER2, clkPER e clkCPU a 3 MHz, in parole povere il modulo Hi-Res ad una frequenza 4 volte superiore rispetto alla CPU ed alle periferiche.