Значения X и Z в Verilog: unknown и high-impedance сигналы

Two-state vs four-state логика

В софте бит - это 0 или 1. В Verilog бит может быть одним из четырёх значений:

• 0 - wire приведён к low.
• 1 - wire приведён к high.
• x - значение wire unknown. Симулятор не может определить.
• z - wire high-impedance. Ничто не приводит его в действие.

Эта four-state-модель существует, потому что у железа такая же проблема. Реальный wire может быть притянут к low, к high, undefined (приводится двумя источниками, которые борются) или плавающим (никакого driver). Симулятор должен моделировать все четыре, чтобы быть полезным.

Как появляется x

Запусти это и посмотри вывод:

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

    // `a` нигде не присваивается.
    assign c = a + b;

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

a объявлен, но никогда не записан, так что он сидит в x. x + 5 даёт x - любая арифметика с unknown даёт unknown. На выходе будет aaaa иксов.

Частые источники x в твоих проектах:

• reg, объявленный, но никогда не сброшенный (большинство синтезируемого Verilog использует явный reset, чтобы их обнулить).
• case-оператор без default, в который попало значение, ни одной ветке не подошедшее.
• wire, который потерял свой единственный driver после рефакторинга.
• Цепочка if/else, где одна ветка не присваивает сигнал, который присваивает другая (latch x, если не покрыто).
• Чтение за пределами вектора или массива.

Распространение X: один бит x ломает всё

Жестокая штука с x - он распространяется. Один бит x в операнде превращает весь результат в x:

module x_propagation;
    initial begin
        $display("0       & 1'bx = %b", 1'b0 & 1'bx);   // 0 - identity AND побеждает
        $display("1       & 1'bx = %b", 1'b1 & 1'bx);   // x
        $display("1       | 1'bx = %b", 1'b1 | 1'bx);   // 1 - identity OR побеждает
        $display("0       | 1'bx = %b", 1'b0 | 1'bx);   // x
        $display("0       + 1'bx = %b", 1'b0 + 1'bx);   // x - арифметика всегда портит
        $display("4'hF    & 4'bxx10 = %b", 4'hF & 4'bxx10);
        $finish;
    end
endmodule

Заметь, что 0 & x - это 0 (AND с 0 всегда даёт 0), а 1 | x - это 1 (OR с 1 всегда даёт 1). Симулятор побитово пессимистичный, но всё равно уважает identities. Арифметика и сравнение не так щедры.

Вот почему один неинициализированный регистр может превратить всю шину выхода в xxxx. Трасируй назад от любого x - найдёшь источник.

Как появляется z

z - значение wire, который никто не приводит:

module z_demo;
    wire [3:0] floating;   // объявлен, без driver
    reg  enable;
    wire data_out;
    reg  data;

    // Tri-state выход: приводит `data`, когда `enable` high, отпускает, когда low.
    assign data_out = enable ? data : 1'bz;

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

        enable = 1; data = 1; #1 $display("приводится:  data_out = %b", data_out);
        enable = 0;            #1 $display("отпущен: data_out = %b", data_out);
        $finish;
    end
endmodule

Два паттерна в этом фрагменте:

• floating просто объявлен и никем не приводится. Дефолтно z.
• data_out - намеренный tri-state. Когда enable low, выход явно отпускается в z. Так bus driver "отпускает", чтобы другой driver мог взять.

На внутренней логике z почти всегда ошибка. На двунаправленном pin или общей шине z - ровно то, что надо.

Сравнение через == vs ===

Обычный оператор равенства == возвращает x, когда у любого операнда есть бит x или 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  - бесполезно
        $display("1'bx == 1'bx = %b", 1'bx == 1'bx);     // x  - тоже бесполезно

        $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

=== (и его пара !==) делает строгое побитовое сравнение, включая x и z. Используй его всегда, когда нужно проверить на или против x/z в testbench. === не синтезируется, но внутри блока initial в testbench это неважно.

Системная функция $isunknown(expr) - самый чистый способ спросить "есть ли в этом выражении биты x или z?" - возвращает 1, если да, 0, если нет.

Использование x как намеренного don't-care

Контроверсиальный, но легитимный паттерн: 'x в default-ветке state machine говорит синтезатору "это состояние недостижимо, оптимизируй свободно":

case (state)
    IDLE:    next_state = go ? RUNNING : IDLE;
    RUNNING: next_state = done ? IDLE : RUNNING;
    default: next_state = 'x;   // недостижимо
endcase

Синтезатор может использовать x, чтобы слить состояния и сократить количество вентилей. В симуляции, если твои рассуждения были неверны и default всё-таки срабатывает, увидишь, как x распространяется от next_state, и баг становится виден сразу.

Используй это только когда продумал, действительно ли default недостижим. Если нет - ставь default в безопасное состояние.

Стандартный рецепт отладки

Смотришь на waveform, полный x. Рецепт:

1. Найди самый ранний x. Иди назад по waveform во времени. Самый ранний сигнал, ставший x, ближе всего к источнику.
2. Найди его driver. Открой исходник. Что присваивает этому сигналу? assign? Блок always?
3. Проверь входы driver. Если RHS у driver содержит x, propagation делает своё дело - баг выше по потоку.
4. Если у driver чистые входы, но он выдаёт x, значит driver неполный. case без default, if без else, регистр без reset.

Большинство x-storm багов сводится к одному из: пропущенный reset, пропущенный default или подмодуль, который не подключён.

Что дальше

Теперь у тебя полная история про типы данных: wire/reg, векторы, parameters, числовые литералы и four-state-логика. Следующая глава начинает использовать всё это для построения выражений - операторы всех мастей, включая bit-level операторы, которые в софте не имели бы смысла.