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;

在组合逻辑中未在敏感度列表中放置右侧会导致综合问题。由于没有这三行，我需要在每个个案中明确地写其他部分，他说是的。

我想知道这种编码样式有什么问题吗？通过在组合逻辑中初始化这些值，是否会导致综合问题或任何类型的问题（也许某些版本或旧的综合工具无法进行合成？）？他说的话对我来说确实有意义，我实际上从未考虑过，因为他说这是软件逻辑，并且每条线都从具有初始条件的逻辑中获得其初始值。我告诉他学校是教给我们的，他就像学校在乎什么，但在工业方面却不在乎。

谢谢您的帮助！猜猜我什至没有一个答案，我也不想说服他，因为团队无论如何都必须坚持一种风格，但是我对他感到困惑，因为我一直看到其他人都在这样做，而且他也是个重担经验，所以...很困惑

Answer 1

首先，您应该使用Verilog-2001的always @(*)或SystemVerilog的更好的always_comb，以便为您自动构建敏感度列表。

您的代码存在问题，是使用this paper中所述的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语句充满了。至于较旧的综合工具，我认为这对于这个特定主题并没有太大的问题，但这是工业界一直在考虑的问题。更大的问题是，如果您的公司配置了下游工具来强制使用较早的结构以降低验证成本。

请信任您的经理在此问题上的经验。行业中的编码风格很大程度上受与其他工程师的协作，成本和传统的影响，而不是受技术细节的影响。在这里，您的经理的经验将很有价值。

可综合代码的Verilog编码样式

2 个答案: