用于可综合代码的verilog编码风格

Question

我编写了如下内容：

always @(state or i1 or i2 or i3 or i4) begin
next = 5'bx;
err = 0; n_o1 = 1;
o2 = 0; o3 = 0; o4 = 0;
case (state) // synopsys full_case parallel_case
IDLE: begin
if (!i1) next = IDLE;
else if ( i2) next = S1;
else if ( i3) next = S2;
else next = ERROR;
end
S1: begin
if (!i2) next = S1;
else if ( i3) next = S2;
else if ( i4) next = S3;
else next = ERROR;**strong text**
...

我的经理当然，在我有一些强烈的争论之前，我不想和他争论，但他回顾了我的代码，并说写作

next = 5'bx;
err = 0; n_o1 = 1;
o2 = 0; o3 = 0; o4 = 0;

在没有将右侧置于敏感性列表中的组合逻辑中将导致综合问题。由于没有这3行，我需要在每个单独的案例中明确地写出else部分，并且他说是。

我想知道这种编码风格有什么问题吗？ 并且它会通过在组合逻辑中初始化这些值而导致合成问题或任何类型的问题（可能某些版本或旧的综合工具不会合成？） 他说的话对我来说很有意义，我实际上从未想过它，因为他说这是软件逻辑，并且每条线在初始条件之前从逻辑中得到它的初始值。 我告诉他学校教给我们这个，他就像学校一样关心任何合成，但行业确实如此。

谢谢您的帮助！ 猜猜我也没有试图说服他什么，即使我有答案，因为团队需要坚持一种风格，但我很困惑，因为我看到其他人一直这样做，他也是一个有吨的人经验，所以...困惑

Answer 1

首先，您应该always @(*)使用来自Verilog-2001的always @(*) ，或者甚至更好地always_comb SystemVerilog中的always_comb ，以便自动构建灵敏度列表。

您的代码的问题是使用full case合成编译指示，如本文所述 。 只要您确定为always块中的每个变量分配了通过块的所有可能流，您的编码样式就不再需要完整的大小写。

Answer 2

我认为你的老板对“软件逻辑”的意思是你的编码风格要求设计师按顺序思考。 换句话说，当我读取你的always块时，我首先被迫考虑所有被初始化为默认值的值，然后我必须评估案例逻辑。 实际上，逻辑将合成为default情况的等价物。 这导致了代表RTL的逻辑与我在脑海中评估你的表达的逻辑之间的差异。 如果你知道自己在做什么，那么大部分时间都应该没问题。 但是你在为一家公司工作，所以你的代码应该考虑到从事项目的其他工程师。 设计流程中的每个不同团队将通过可能不同的镜头来查看相同的逻辑（例如，物理设计团队不关心Verilog而是合成的RTL）。 如果我们编写Verilog来反映最终的RTL（即“硬件逻辑”），那么每个人都在以类似的方式分析逻辑。 如果我查看电路中的输出并且我知道给定时间步长的所有输入值，那么我可以通过电路直观地跟踪输出并确定其值而不考虑其他逻辑。 您的Verilog代码应以相同的方式编写。

总而言之，您的初始化语句只不过是RTL中选择多路复用器的另一种情况。 所以，你应该这样写。 使用default情况并在每种情况下显式分配块的每个输出。 这通常被认为是最佳做法。 它可能不是编写Verilog最聪明或最优雅的方式，但它最具可读性并且导致错误少得多（在工业中，人们更关心设计验证以降低成本而不是Verilog的聪明才智）。

另外，正如@ dave_59所提出的那样，如果你使用full_case Synopsis指令，那么它将为你创建默认输出驱动程序，其输出设置为“不关心”。 这不是任何人想要的结果，它将由验证团队标记。 要解决这个问题，你需要确保通过将它们添加到像老板提到的所有案例中来分配每个输出。 如果你无论如何都被迫这样做，那么full_case是多余的，因为你已经明确地将case语句填满了。 至于较旧的综合工具，我认为这个特定主题并不是一个大问题，但它是一个始终在工业界给予的考虑。 如果您的公司已配置下游工具以强制使用较旧的结构以降低验证成本，那么问题就更大了。

相信您的经理在这个问题上的经验。 工业中的编码风格很大程度上受到与其他工程师，成本和遗产的合作的影响，而不是技术细节。 这是您经理的经验值得珍惜的地方。