Verilog проблема многоступенчатого конвейерного буфера

Question

Я работаю над школьным проектом для двухступенчатого конвейерного процессора в Verilog HDL и столкнулся с проблемой, которая поставила меня в тупик на несколько дней.Я добавлю небольшие фрагменты кода и картинку сигналов, которые я получаю через ModelSim через мое описание.Я просто беру вывод из моего ALU:

ALU #(BUS_WIDTH(BUS_WIDTH)) alu (
    .A(Amux),
    .B(Bmux),
    .sel(ALUsel),
    .Dout(ALUout)
);

Затем я передаю его непосредственно в буфер между моими каскадами в одном и том же файле следующим образом (другие сигналы и данные, которые буферизируются, удаляются для простотычтение):

Buffer #(.BUS_WIDTH(BUS_WIDTH)) buff(
    .clk(clk),
    .reset(reset),
    .aluA(ALUout),
    .aluB(ALUoutM),
);

Внутренняя часть модуля буфера выглядит следующим образом (я снова удаляю все остальное, буферизуемое для удобства чтения:

module Buffer(
    input clk,
    input reset,
    input [31:0] aluA,
    output reg [31:0] aluB
);

    always @(posedge clk)
    begin
        if (~reset)
        begin
            aluB <= 32'h00000000;
        end else
        begin
            aluB <= aluA;
        end
    end
endmodule

Следующее изображение - это то, чтоУ меня проблемы с:

Это происходит через несколько циклов после запуска испытательного стенда и успешного запуска предыдущих циклов. Глядя на изображение, верхний сигналALUout и второй сигнал - ALUoutM. Мой желаемый результат - чтобы мой сигнал ALUoutM соответствовал моему сигналу ALUout из предыдущего тактового цикла (я убедился, что полный тактовый цикл - это период между изменениями сигнала на изображении).этот желаемый результат виден во всех циклах, предшествующих этому. Между первым и вторым циклами,результат не такой, как хотелось бы, но затем возвращается к правильности.Я трижды проверил и убедился, что мой ALUoutM не управляется никакими другими сигналами.Я в основном пытаюсь выяснить, делаю ли я ошибку новичка с verilog, о которой я не знаю.Спасибо за любую помощь.

ДОПОЛНЕНИЕ

Согласно комментариям Олдфарта (мне нравится это имя), я смог добавить сигналы буфера и в мой симулятор, но он отображаетточно такое же поведение, как и входные сигналы.На следующем изображении вы заметите правильное поведение для первых 4 тактов, а затем из буфера появится случайное значение 0x00000000.Тогда это правильно для еще одного тактового цикла перед тем, как полностью улететь с рельсов.

Answer 1

Хорошо, спасибо Олдфарту (все еще люблю это имя) за то, что он дал мне совет по этому вопросу.Поговорив об этом с профессором и помощником преподавателя, я изменил все свои MUX для включения сигнала

always @ ( * )

, который я не считал проблемой, когдаотправив вопрос.Ранее я создавал их как

always @ (sel or input_a or input_b or ... or input_N)

Это не было немедленно распространять мои данные, как MUX можно было ожидать.Я полагаю, что это потому, что все входы не попадают в MUX одновременно, что приводит к тому, что значение выхода может изменяться столько же раз, сколько и количество сигналов, которые изменились (если только вам не повезлочтобы каждый сигнал достигал одновременно).Это потенциально дает вам неправильный сигнал много раз, пока все входы не распространятся на MUX.Короче говоря, кто знает, какие значения вы в конечном итоге синхронизируете, если вы делаете это так, как я это делал изначально.

Это, наряду с "регистрацией" моих выходных данных в моих модулях, решило мою проблему.Для тех, кто не уверен, что я имею в виду, когда я объявляю свои результаты, я делаю это как

output reg [(width - 1):0] output_x

, а не

output [(width - 1):0] output_x

Я не уверен на 100%, почему это помогло, но когда я вернулся и сделал это, он заставил весь процессор дать мне гораздо более приятные сигналы, которые действовали, как я ожидал.Я полагаю, что это потому, что это приводит к тому, что все выходы «защелкиваются».Если бы кто-то мог объяснить, почему это помогает, я был бы очень признателен.