optimization - 计算结果和多路复用与否

Question

这里使用伪代码。这些风格有什么优点和缺点:

假设你有一个可以做加法、和、或和异或的 alu。是否最好让代码始终计算可能的答案，然后根据操作码选择答案(在这种情况下为 one hot):

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

从逻辑和可读性的层面考虑这一点。前两种形式在可读性方面还不错，但都不必要地体现了优先级，并且会导致更多层次的逻辑。从这些指标中的任何一个来看，第三种形式也不是那么好。最后，没有明显的理由在这里使用单热编码而不是二进制编码。这是我编码的方式:

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

您可以在 this article 中了解有关有效使用 case 语句的更多信息。来自优秀Sunburst Design网站(没有从属关系，只是以前的学生)。

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