总是用一个非阻塞赋值 @* 阻塞 - 好、坏还是不相关？答案

【问题标题】：always @* block with a single non-blocking assignment - good, bad or irrelevant?总是用一个非阻塞赋值 @* 阻塞 - 好、坏还是不相关？
【发布时间】：2012-06-23 16:43:50
【问题描述】：

到目前为止，在我读过的所有书籍中都提到的一般经验法则是，您必须在由时钟的上升沿或下降沿驱动的 always 块中使用非阻塞分配。相反，阻塞赋值必须用于组合逻辑描述。这条规则对我来说很有意义，示例的作者完全遵循它。

但是，我在其中一个生产代码中发现了以下 Verilog：

always @* begin
   in_ready <= out_ready || ~out_valid;
end

请注意，正在使用非阻塞赋值 <=。我认为在这种情况下没有任何区别，因为没有多重分配。但是，我似乎找不到任何解释。所以问题是 - 无论是在给定的 always 块的范围内还是作为更大设计的一部分，它是否有任何区别？

【问题讨论】：

标签： verilog

【解决方案1】：

当然，这违反了我的编码准则 #3：http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf)，但它会起作用。

避免对代码组合逻辑使用非阻塞赋值的原因是仿真性能。在 Munkymorgy 的示例中，在 always 块触发后，您将评估所有方程的右侧 (RHS)，回到 always 块的顶部，更新方程的 LHS，这将再次触发always 块，这将再次强制模拟器评估方程的 RHS，转到 always 块的顶部，然后更新方程的 LHS。对于较大的块，这可能会导致通过 always 块进行多次迭代，并产生相应的模拟损失。

在您的简单 1 行示例中，没有内部模拟惩罚，但其他地方可能存在交叉分配惩罚。

优秀的编码员会始终保持良好的编码习惯。我会更改代码。如果更改代码会破坏模拟结果，那么代码中的其他地方就会隐藏额外的不良编码习惯。代码不应该那么脆弱。

【讨论】：

这里也有一个例外，正如您在论文中提到的，我们需要使用 always@(*) 中的非阻塞分配来模拟门延迟。（我在这里写了一个答案：stackoverflow.com/a/68113200/12311164）

【解决方案2】：

不相关但不好的做法。

我怀疑单个分配会导致任何副作用。 always 块将触发右侧的任何更改，更新 in_ready。没有什么可阻塞的，所以非阻塞不会引起问题。

如果更大的设计有：

always @* begin 
  in_ready    <= out_ready || ~out_valid  ;
  other_ready <= in_ready  || other_ready ;
end

我不太确定，因为它是组合的，它可能只需要一个额外的增量步骤来解决。

【讨论】：

谢谢。是的，您的代码示例绝对不仅显示了一种不好的做法，而且除非它真的打算那样，否则它不会真正按预期工作，这没有多大意义。我想知道反对者对此的看法是什么。你其实是对的。我在 EE stackexchange（electronics.stackexchange.com/questions/34287/flip-flop-vs-combinatorial-description-what-exactly-is-the-difference/）上确认了我的一个更大问题的一部分。感谢您的帮助！

【解决方案3】：

如果您了解电路的表现方式，它的选择还不错比如

总是@* 开始 b

因此，在此示例代码中，当灵敏度列表中的所有输入都上升或下降时，always 块内开发的完整电路将被激活，从而改变其当前状态
现在 b
现在设计已经完成，或者编译器以这样的方式合成电路，下一条语句 a=b 此处的线是从旧值而不是更新后的 b 中取出的，并提供给 a ; 这么简单
如果你希望同样的事情发生，欢迎你做任何问题都不会出现在可综合性中

【讨论】：

【解决方案4】：

如果要模拟门延迟，则需要始终 @(*) 中的非阻塞赋值。

例如，下面的代码在输出端正确模拟了一个延迟为 3 ns 的 OR 门。在这种情况下，阻塞分配将不起作用。

always @(*) begin
  a <= #3 b | c;
end

进一步阅读：

【讨论】：