Perché i fermi inferiti sono cattivi?

Il mio compilatore si lamenta dei latch inferiti nei miei loop combinatori ( always @(*), in Verilog). Mi è stato anche detto che i dispositivi di chiusura dedotti dovrebbero essere preferibilmente evitati.

Cosa c'è di esattamente sbagliato nei chiavistelli inferiti? Certamente facilitano la scrittura di loop combinatori.

Un "latch" è diverso da un "Flip-Flop" in quanto un FF cambia il suo output solo in risposta a un fronte di clock. Un latch può modificare il suo output in risposta a qualcosa di diverso da un clock. Ad esempio, un SR-Latch ha un ingresso set e reset e se uno di essi è attivo, l'uscita può cambiare. Dove come SR-FF risponde solo a un set o reset quando c'è anche un fronte di clock.

In un FPGA, vuoi che la tua logica sia completamente sincrona. Ciò significa che tutti gli elementi di archiviazione (come gli FF) sono tutti sincronizzati da una singola sorgente di clock. Tutto ciò che è asincrono a quell'orologio deve essere trattato con molta attenzione, altrimenti si verificheranno errori di temporizzazione.

Un latch è fondamentalmente un elemento di archiviazione asincrono. Non ha input di clock, quindi non può essere sincronizzato con nessun clock. Dovrei notare che ci sono FF con ingressi di reset e reset asincroni, e questi dovrebbero essere trattati con la stessa cura dei normali latch.

Analizzare tutti i problemi di temporizzazione che i latch possono causare è molto al di là di ciò che può essere trattato qui, ma lasciatemi fare un esempio:

Diciamo che hai un SR-Latch e vuoi che sia impostato ogni volta che un contatore a 8 bit raggiunge un certo valore. Non sono sicuro di quale sarebbe il codice Verilog, ma in VHDL il codice è: set <= '1' quando count = "11010010" else '0'; Quel segnale impostato va all'ingresso impostato sul nostro SR-Latch.

La logica che si genera è puramente combinatoria; un mix di and-gate, or-gate e inverter (o LUT). Ma i percorsi del segnale attraverso quella logica combinatoria non sono sempre perfetti e il segnale "set" potrebbe avere dei difetti. Il percorso del segnale attraverso un determinato gruppo di gate potrebbe richiedere più tempo di un altro gruppo, facendo sì che l'uscita impostata diventi attiva per un breve momento prima che l'uscita si stabilizzi nello stato finale.

Questo glitch di uscita potrebbe causare l'impostazione del nostro SR-Latch, anche se non era previsto. Se passiamo da un SR-Latch a un SR-FF, con lo stesso clock del contatore, l'orologio SR-FF attenderà un intero ciclo di clock prima di cambiare stato. In sostanza attenderà che il segnale impostato si stabilizzi prima di guardarlo.

Se i percorsi attraverso la logica combinatoria per il segnale impostato vengono semplicemente instradati in modo diverso (causando ritardi diversi), anche il comportamento del glitch cambierà. La logica potrebbe funzionare bene, ma poi, poiché hai cambiato qualcosa di completamente indipendente, questa logica viene instradata in modo diverso e quindi il bug si apre. La temperatura e la tensione cambieranno anche la temporizzazione del segnale e quindi il comportamento del glitch.

Questo incerto nei tempi è il motivo per cui dovresti evitare i fermi nella tua logica. Gli FF sono molto più sicuri da usare. Questo è il motivo per cui il tuo compilatore ti avverte dei latch, dal momento che è facile fare un latch errato e probabilmente non lo vuoi comunque.

Certo, a volte sono necessari i fermi. Devi solo usarli molto raramente, solo quando assolutamente necessario, e quindi devi progettare la logica giusta in modo che non ci siano problemi.

Cosa rende un fermo inferito?
Per la logica combinatoria, l'uscita del circuito è una funzione di solo ingresso e non deve contenere memoria o stato interno (latch).

In Verilog, una variabile manterrà il suo valore precedente se non gli viene assegnato un valore in un blocco sempre . È necessario creare un latch per memorizzare questo valore attuale.

Un'istruzione if-else incompleta genererà blocchi. Un'istruzione if-else è considerata "incompleta" se lo stato dell'uscita non è definito per tutte le possibili condizioni di input. Lo stesso vale per un'istruzione case incompleta o un'istruzione case che non ha un valore predefinito: item.

Perché i fermi inferiti sono cattivi?
I latch dedotti possono fungere da "segnale di avvertimento" che la progettazione logica potrebbe non essere implementata come previsto. Neldisegno potrebbe mancare un'istruzione if-else o case cruciale.

I fermi possono portare a problemi di temporizzazione e condizioni di gara. Possono portare a un feedback combinatorio - il routing dell'output verso l'ingresso - che può essere imprevedibile.

Per evitare la creazione di blocchi inferiti:

• Includere tutti i rami di un caso o di caso dichiarazione
• Assegna un valore a ogni segnale di uscita in ogni ramo
• Utilizzare le assegnazioni predefinite all'inizio della procedura, quindi verrà assegnato ogni segnale.

Alcune parti sono state parafrasate da "FPGA Prototyping by Verilog Esempi" di P. Chu

I latch sono molto difficili da usare in FPGA o CPLD, quindi molte persone li evitano completamente. Uno dei motivi è che molti FPGA non hanno un fermo incorporato, quindi sono fatti di porte logiche, questo può causare problemi di temporizzazione.
Inoltre non hai alcun controllo sui ritardi nei tempi e sulle condizioni di gara quando usi un latch (a meno che non ci sia un elemento nativo)

Vorrei sconsigliare l'uso dei dispositivi di chiusura a meno che non si possa assolutamente fare a meno di essi (ad es. Impiegare del tempo per soddisfare una frequenza di clock massima necessaria) e utilizzare tecniche di codifica per rendere meno probabili le chiusure accidentali.

I progetti di logica sequenziale costruiti usando la logica combinatoria e il feedback generalmente fanno un presupposto che sembrerebbe ragionevole quando si usano gate fisici: che l'uscita di un gate non cambierà in risposta a un cambiamento nell'input, fino a qualche tempo dopo che l'input è effettivamente cambiato. Ci sono alcune occasioni in cui tale ipotesi potrebbe non valere quando si usano porte reali (ad esempio se una porta NOR veloce e un inverter veloce sono entrambe guidate da un segnale che sale lentamente da VSS a VDD e se l'inverter passa a 1,2 volt mentre il NOR il gate non si commuta fino a 1,7 volt, il gate NOR potrebbe vedere l'uscita dell'inverter abbassarsi prima di vedere che il segnale di aumento lento è aumentato) ma tali problemi possono generalmente essere risolti aggiungendo un buffer ogni volta che un cambiamento lento il segnale viene indirizzato a più di una destinazione. Sfortunatamente,

Il problema è che, se non diversamente specificato esplicitamente, un compilatore FPGA può sostituire arbitrariamente un circuito combinatorio con un circuito totalmente diverso che ha lo stesso comportamento in regime stazionario, ma può avere tempistiche completamente diverse. Ad esempio, supponiamo che una complessa funzione combinatoria F comprenda sei ingressi da U a Z. F viene alimentato direttamente al circuito P e (F NAND Z) viene alimentato al circuito Q. Il compilatore potrebbe rendersi conto che il valore alimentato a Q dipenderà solo da F quando Z è alto e può calcolare una funzione F 'che è come F tranne per il fatto che Z è assunto alto; Q può quindi essere alimentato con (F 'NAND Z) anziché (F NAND Z). Sarebbe del tutto possibile che la realizzazione più efficiente di P avrebbe cinque ritardi di gate, ma la realizzazione più efficiente di Q ne avrebbe solo due. Così,

Se un circuito ha un circuito di feedback combinatorio, un compilatore FPGA dovrà aggiungere nodi di segnale fisici che avranno, fisicamente, un ritardo positivo (un circuito di feedback a ritardo zero non può esistere nel mondo reale), ma non c'è garanzia che tali nodi verrebbero aggiunti nei punti necessari per far funzionare il circuito come desiderato. Né vi è nemmeno la garanzia che una leggera modifica al design non causi il passaggio dal compilatore a un posizionamento arbitrario che funziona nel mondo reale, a un diverso posizionamento arbitrario che sembra non riuscire.

I dettagli su come catturare un fermo nel design sono brevemente spiegati in questo link.

https://www.doulos.com/knowhow/fpga/latches/