Valori X e Z in Verilog: segnali sconosciuti e ad alta impedenza

Logica a due stati e a quattro stati

Nel software un bit vale 0 o 1. In Verilog un bit può assumere uno di quattro valori:

• 0: il wire è pilotato basso.
• 1: il wire è pilotato alto.
• x: il valore del wire è sconosciuto. Il simulatore non può saperlo.
• z: il wire è in alta impedenza. Nessuno lo sta pilotando.

Questo modello a quattro stati esiste perché l'hardware ha lo stesso problema. Un wire reale può essere collegato a massa, collegato all'alimentazione, indefinito (pilotato da due sorgenti in conflitto) o flottante (senza alcun driver). Per essere utile, il simulatore deve modellare tutti e quattro i casi.

Come compare x

Esegui questo codice e guarda l'output:

module unknown_demo;
    reg [3:0] a;
    reg [3:0] b;
    wire [3:0] c;

    // `a` is never assigned.
    assign c = a + b;

    initial begin
        b = 4'd5;
        #1 $display("a=%b b=%b c=%b", a, b, c);
        $finish;
    end
endmodule

a è dichiarato ma mai scritto, quindi resta a x. Sommare x + 5 produce x: qualsiasi operazione aritmetica con un valore sconosciuto produce un valore sconosciuto. Nell'output, al posto di aaaa compare una fila di x.

Le fonti più comuni di x nei tuoi progetti:

• Un reg dichiarato ma mai resettato (la maggior parte del Verilog sintetizzabile usa un reset esplicito per azzerarli).
• Un'istruzione case senza default, raggiunta da un valore di ingresso che nessun caso gestisce.
• Un wire che ha perso il suo unico driver dopo un refactoring.
• Una catena if/else in cui un ramo non assegna un segnale che l'altro invece assegna (se il caso non è coperto si crea un latch che tiene x).
• Leggere oltre la fine di un vettore o di un array.

Propagazione di X: basta un bit x per rovinare tutto

La cosa crudele di x è che si propaga. Un solo bit x in un operando rende x l'intero risultato:

module x_propagation;
    initial begin
        $display("0       & 1'bx = %b", 1'b0 & 1'bx);   // 0 - the AND identity wins
        $display("1       & 1'bx = %b", 1'b1 & 1'bx);   // x
        $display("1       | 1'bx = %b", 1'b1 | 1'bx);   // 1 - the OR identity wins
        $display("0       | 1'bx = %b", 1'b0 | 1'bx);   // x
        $display("0       + 1'bx = %b", 1'b0 + 1'bx);   // x - arithmetic always taints
        $display("4'hF    & 4'bxx10 = %b", 4'hF & 4'bxx10);
        $finish;
    end
endmodule

Nota che 0 & x vale 0 (AND con 0 dà sempre 0) e 1 | x vale 1 (OR con 1 dà sempre 1). Il simulatore è pessimista bit per bit ma rispetta comunque queste identità. L'aritmetica e i confronti non sono altrettanto generosi.

Ecco perché un solo registro non inizializzato può portare a xxxx un intero bus di uscita. Risali all'indietro da qualsiasi x e troverai la sorgente.

Come compare z

z è il valore di un wire che nessuno sta pilotando:

module z_demo;
    wire [3:0] floating;   // declared, no driver
    reg  enable;
    wire data_out;
    reg  data;

    // A tri-state output: drives `data` when `enable` is high, releases when low.
    assign data_out = enable ? data : 1'bz;

    initial begin
        $display("floating = %b", floating);   // zzzz

        enable = 1; data = 1; #1 $display("driven:  data_out = %b", data_out);
        enable = 0;            #1 $display("released:data_out = %b", data_out);
        $finish;
    end
endmodule

In quel frammento ci sono due pattern:

• floating è solo dichiarato e mai pilotato. Per impostazione predefinita vale z.
• data_out è un tri-state voluto. Quando enable è basso, l'uscita viene rilasciata esplicitamente a z. È così che il driver di un bus "molla la presa" per lasciare il controllo a un altro driver.

Nella logica interna, z è quasi sempre sbagliato. Su un pin bidirezionale o su un bus condiviso, z è esattamente ciò che serve.

Confrontare con == e ===

Il normale operatore di uguaglianza == restituisce x quando uno dei due operandi ha un bit x o z:

module compare_demo;
    initial begin
        $display("1'b1 == 1'b1 = %b", 1'b1 == 1'b1);     // 1
        $display("1'b1 == 1'bx = %b", 1'b1 == 1'bx);     // x  - not useful
        $display("1'bx == 1'bx = %b", 1'bx == 1'bx);     // x  - also not useful

        $display("1'b1 === 1'b1 = %b", 1'b1 === 1'b1);   // 1
        $display("1'b1 === 1'bx = %b", 1'b1 === 1'bx);   // 0
        $display("1'bx === 1'bx = %b", 1'bx === 1'bx);   // 1

        $display("$isunknown(1'bx) = %b", $isunknown(1'bx));   // 1
        $finish;
    end
endmodule

=== (e il suo compagno !==) esegue un confronto rigoroso bit per bit, compresi x e z. Usalo ogni volta che in un testbench devi verificare la presenza o l'assenza di x/z. === non è sintetizzabile, ma dentro un blocco initial di un testbench non importa.

La funzione di sistema $isunknown(expr) è il modo più pulito per chiedere "questa espressione ha qualche bit x o z?": restituisce 1 se sì, 0 se no.

Usare x come don't-care intenzionale

Un pattern discusso ma legittimo: 'x nel caso default di una macchina a stati dice al sintetizzatore "questo stato è irraggiungibile, ottimizza pure":

case (state)
    IDLE:    next_state = go ? RUNNING : IDLE;
    RUNNING: next_state = done ? IDLE : RUNNING;
    default: next_state = 'x;   // unreachable
endcase

Il sintetizzatore può sfruttare la x per fondere stati e ridurre il numero di porte. In simulazione, se il tuo ragionamento era sbagliato e il default viene raggiunto, vedrai x propagarsi da next_state e il bug diventa subito visibile.

Usalo solo dopo aver verificato con attenzione che il default sia davvero irraggiungibile. Se non l'hai fatto, imposta invece il default su uno stato sicuro.

Ricetta di debug tipica

Hai davanti una forma d'onda piena di x. La ricetta:

1. Trova la x più precoce. Scorri la forma d'onda indietro nel tempo. Il primo segnale che passa a x è quello più vicino alla sorgente.
2. Trova il suo driver. Apri il sorgente. Cosa assegna questo segnale? Un assign? Un blocco always?
3. Controlla gli ingressi del driver. Se il lato destro del driver contiene qualche x, la propagazione sta facendo il suo lavoro: il bug è più a monte.
4. Se il driver ha ingressi puliti ma produce x, il driver è incompleto. Un case senza default, un if senza else, un registro senza reset.

Quasi tutti i bug con una tempesta di x si riducono a uno di questi: reset mancante, default mancante o un sottomodulo non collegato.

Cosa viene dopo

Ora hai il quadro completo dei tipi di dato: wire/reg, vettori, parametri, letterali numerici e il modello logico a quattro stati. Il prossimo capitolo inizia a usare tutto questo per costruire espressioni: operatori di ogni tipo, compresi quelli a livello di bit che nel software non avrebbero senso.