计算结果并进行复用或不复用

Question

这里使用伪代码。这些风格有优点和缺点吗：

假设你有一个可以进行加法、与、或和异或运算的 alu。是否最好使用始终计算可能答案的代码，然后根据操作码选择答案（在本例中是一个热门答案）：

alu_add = a + b;
alu_and = a & b;
alu_or  = a | b;
alu_xor = a ^ b;

...

if(opcode[0])      alu_out = alu_add;
else if(opcode[1]) alu_out = alu_and;
else if(opcode[2]) alu_out = alu_or;
else if(opcode[3]) alu_out = alu_xor;

另一种方法是这样编码：

if(opcode[0])      alu_out = a + b;
else if(opcode[1]) alu_out = a & b;
else if(opcode[2]) alu_out = a | b;
else if(opcode[3]) alu_out = a ^ b;

我也将其视为：

alu_add = a + b;
alu_and = a & b;
alu_or  = a | b;
alu_xor = a ^ b;

...

alu_out = 
  ( 8{opcode[0]} & alu_add ) |
  ( 8{opcode[1]} & alu_and ) | 
  ( 8{opcode[2]} & alu_or ) |
  ( 8{opcode[3]} & alu_xor );

有吗这两种方法各有利弊，还是最终结果相同？

Answer 1

从逻辑和可读性的角度考虑这一点。前两种形式在可读性方面很好，但都不必要地体现了优先级，并且会导致更多层次的逻辑。从这两个指标来看，第三种形式也不是那么精彩。最后，没有明显的理由在此处使用 one-hot 编码而不是二进制编码。下面是我的编码方式：

parameter ALU_ADD = 2'b00;
parameter ALU_AND = 2'b01;
parameter ALU_OR  = 2'b10;
parameter ALU_XOR = 2'b11;

reg [1:0]  opcode;  // 2 bits for binary coding vs. 4 for one-hot

// 以及稍后，在您的always块中：

case (opcode)  // synopsys parallel_case
    ALU_ADD: alu_out = a + b;
    ALU_AND: alu_out = a & b;
    ALU_OR:  alu_out = a | b;
    ALU_XOR: alu_out = a ^ b;
endcase

这里我显式地为​​ALU操作码分配了值，避免了“幻数”并使其他人更容易理解正在发生的事情。我还使用了 case 语句并应用了一条指令，该指令告诉我的综合工具不能匹配多个表达式，因此不会推断出优先级编码器。我没有命名中间信号（alu_add 等），因为这些都是微不足道的操作，但当我想要方便地访问这些信号时（例如在波形查看器中仿真后查看它们的值），我经常这样做。

您可以在这篇文章中了解有关有效使用 case 语句的更多信息，该文章来自优秀的 Sunburst Design 网站（无隶属关系，只是以前的学生）。

最后，关于您的问题，“是否最好使用始终计算可能答案的代码，然后根据操作码选择答案”——请记住，Verilog 是一种硬件描述语言。无论如何，此页面上的所有实现始终都在计算所有内容。它们的不同之处在于逻辑级别和可读性。看看这个页面，这表明我的实现超出操作本身的 1 级逻辑，其中 if-else 实现具有 3 级附加逻辑。

Answer 2

前两个将给出相同的逻辑，但您将在 alu_out 上获得锁存器，因为您的 if else 块（您的优先级编码器）没有最终的else< /代码>。 （无论如何，这对于 verilog 来说是正确的）。如果您的时间紧迫，您可能会遇到优先级编码器所暗示的长路径问题。

在第三个版本中，您将获得更加“并行”的结构，这可能更适合计时。它不会卡住。

在所有三个版本中，无论操作码是什么，四个操作中的每一个都将崩溃。这将会产生权力影响。

我认为第一个版本在清晰度方面胜出，您可以在调试时在波形查看器中查看每个单独的操作。除非时间、面积或功率限制受到损害，否则编写不易阅读的内容是没有意义的。