阻塞赋值和非阻塞赋值在仿真器中的不同行为表现

justforfunred

在debug的时候发现一个FIFO在存储数据的时候把本来预期在时钟沿跳变以后的数据打入了FIFO。发现和阻塞赋值和非阻塞赋值的差异有关。为了理解这个问题，做了个简单的实验。实现了一个简单的2级同步寄存器，然后再testbench里面试着使用两种不同的方式给同步寄存器赋值：
1. always @ (posedge clk or negedge rst_n)
       begin
       if (~rst_n)
         D=32'd0;
       else D<=D+1'b1;
       end


2. always @ (posedge clk or negedge rst_n)
       begin
       if (~rst_n)
         D =32'd0;
       else D =D+1'b1;
       end
使用第一种激励同步寄存器的行为和预期的一致，在时钟上升沿的时候采的是上一个周期的数据。使用第二种激励则采的是累加以后的数据。我在vcs里面把delta cycle打开看了看，两种方式在vcs的timeline里面都是一样的，先更新时钟，再更新A数据线，然后更新同步寄存器里面的2个寄存器。
第二种方式在编程规范里肯定是不推荐的，但是不理解的是为什么仿真器的表现是不同的？如果仿真器这么解释感觉有些组合逻辑的输出需要加延时才能和期望的行为一致了。有哪位能够帮忙解释一下么？谢谢了

jun_dahai

这就是为什么要求规范代码了
对于不规范的代码，不同的仿真器当然会有不同的解释了，因为它们是不同的人开发的，对不规范的解析也就有所差异

worenimamai

这不是阻塞与非阻塞的差异吗 最基本的语法阿

zf1650

在统一进程里不应该既有非阻塞又有阻塞，也就是说第一种方法的复位赋值也应该是（d<=32'd0;）。上跳沿采样（无论是阻塞还是非阻塞），本身就是插入了触发器。只是一个进程中所有的非阻塞赋值在仿真时认为是在边沿到来后同时执行（在这个进程中要慢于阻塞赋值），所以有可能前面一个信号的赋值是阻塞赋值，而下一个采样的赋值是非阻塞的话，可能前面那个要快一点（仿真时阻塞执行完之后才同时执行所有非阻塞），从而导致你所述的结果。

mioyo

在always块中，这种写法，建议使用非阻塞赋值，消除竞争冒险

vin3ent

其实不太清楚你的仿真情况到底是什么样子，可能贴个波形更好一点。
但是阻塞非阻塞的影响和延时关系不大，而是编译器处理顺序不同，并且处理顺序是和综合出来的电路密切相关的。