代码之家 › 专栏 › 技术社区 › old_timer

是否计算结果和mux

vhdl verilog optimization

old_timer · 技术社区 · 16 年前

假设您有一个alu可以执行加法、and、or和xor。是否最好让代码始终计算可能的答案,然后根据操作码选择答案(在本例中为单选):

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 );

这两种方法都有优点和缺点吗?或者它们最终的结果是一样的吗?

2 回复 | 直到 16 年前

jlf 16 年前

从逻辑和可读性的角度考虑这一点。前两种形式在可读性方面很好,但都不必要地体现了优先级,并将导致更高层次的逻辑。从这两个指标来看,第三种形式也不太妙。最后,没有明显的理由在这里使用一个热编码而不是二进制编码。下面是我如何编写代码的:

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

//稍后,在“始终”块中:

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等),因为这些都是琐碎的操作,但当我想要方便地访问这些信号(例如在波形查看器中模拟后查看它们的值)时,我经常这样做。

this article 从优秀的 Sunburst Design

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

Marty 16 年前

前两个将给出相同的逻辑,但您将得到一个闩锁 alu_out 因为你的 if else 块(您的优先级编码器)没有最终 else . (无论如何,verilog也是如此)。如果您的时间很紧,您可能会遇到优先级编码器所暗示的长路径问题。

在所有三个版本中,无论操作码是什么,四个操作中的每一个都会发出咔哒声。这将对权力产生影响。

我认为,为了清晰起见,第一个版本是成功的,在调试时,您可以在波形查看器中获得每个单独的操作。除非时间、面积或功率限制受到影响,否则编写不那么容易阅读的代码是没有意义的。