Verilog与模拟器非确定性探讨：多信号同步变化时的执行逻辑疑问

一、Verilog中的非确定性定义 #

非确定性指的是Verilog标准未强制规定执行顺序的场景下，不同模拟器可能产生不同结果，其根源在于事件调度模型中部分阶段允许模拟器自主选择执行顺序。例如同一时间步内，属于同一优先级队列的多个独立事件，标准未明确执行顺序，不同厂商的模拟器可能按不同逻辑处理，导致最终结果存在差异。

二、同一时间步内控制流的切换可能性 #

可以。Verilog的事件调度采用分阶段队列模型（活跃事件队列、非活跃事件队列等），模拟器处理活跃事件时，允许暂停当前事件的执行，优先处理其他同优先级的活跃事件，之后再回到暂停的事件继续执行。这种灵活的调度规则正是部分非确定性场景的来源。

三、你的测试代码分析误区 #

先看你的测试代码：

module test;
    reg [1 : 0]c, d;
    reg a, b;
    initial #5 begin
        a = 0;
        b = 0;
    end

    always@(*)begin
        d = {a ,b};
        c = {a, b};
    end
endmodule

你的分析存在两处关键错误：

1. 阻塞赋值的执行逻辑误解 #

initial块中的a=0和b=0是阻塞赋值，属于同一个事件的连续执行语句，模拟器会一次性执行完这两个赋值，不会中途暂停去处理always块的触发事件。也就是说，a和b的值会先被全部更新为0，之后模拟器才会处理always@(*)触发的执行请求。

2. always@(*)的触发机制误解 #

即使退一步假设always块在b=0执行前被触发，当b后续更新为0时，会再次触发always@(*)块执行。此时a和b均为0，always块会重新执行所有语句，将d和c覆盖为{0,0}，最终结果仍会是预期值，不会停留在{0,x}。

结论 #

你的测试代码场景不存在非确定性，结果必然是{0,0}。Verilog的非确定性仅出现在标准未明确执行顺序的同优先级独立事件场景，而你的代码中事件执行顺序是由阻塞赋值的特性和always@(*)的触发规则明确约束的。

内容的提问来源于stack exchange，提问作者chen zhang