如何理解凿子语言中的节拍？答案

【问题标题】：How to understand the beat in chisel language?如何理解凿子语言中的节拍？
【发布时间】：2021-09-22 08:32:05
【问题描述】：

我正在研究riscv-Boom的设计。它是用chisel设计的。当我阅读它的源代码时，我总是无法理解这些电路中的信号何时会得到。正常程序是一一执行的。但是像 chisel 这样的硬件语言却不是。

https://github.com/riscv-boom/riscv-boom/blob/master/src/main/scala/exu/issue-units/issue-slot.scala 比如上面的链接就是Boom中Issue-slot的源码。

 103:  val next_uop = Mux(io.in_uop.valid, io.in_uop.bits, slot_uop)
 113:  state := io.in_uop.bits.iw_state
 126:  next_state := state
 127:  next_uopc := slot_uop.uopc
 128:  next_lrs1_rtype := slot_uop.lrs1_rtype
 129:  next_lrs2_rtype := slot_uop.lrs2_rtype
 155   slot_uop := io.in_uop.bits
 208:  for loop

这是上面链接中 IssueSlot 类中的一些代码。对于凿子硬件语言，这些:= 应该表示它们是通过电线连接在一起的。那么这些信号会同时变化吗？比如io.in_uop.valid为真时，上面的代码是不是同时赋值？

例如，当前 uop 为 fmul，in_uop= 为 fadd。当io.in_uop.valid时，上面的代码会同时执行。但是有一个问题。

origin 
     uop = fmux
when io.in_uop.valid
     103:  val next_uop = io.in_uop.bits       (fadd uop)
     113:  state := io.in_uop.bits.iw_state    (fadd state)
     126:  next_state := state                  (fmux state)
     127:  next_uopc := slot_uop.uopc             (fmux uopc)
     128:  next_lrs1_rtype := slot_uop.lrs1_rtype (fmux lrs1_rtype )
     129:  next_lrs2_rtype := slot_uop.lrs2_rtype (fmux lrs2_rtype )
     155   slot_uop := io.in_uop.bits              (faddlrs2_rtype )
     208:  for loop

当io.in_uop.valid为真时，此时的发送槽会输入fadd信息。同时，原来的fmul信息仍会输出到下一个相关信号。这应该是不合理的。问题出在哪里？

对于第207行的for循环，我还是觉得很难理解。 for 循环会一次性执行吗？比如我用for循环遍历队列，for循环什么时候结束？

如果有人愿意回答我，我将非常感激！

【问题讨论】：

标签： scala cpu riscv chisel

【解决方案1】：

首先

a := b 表达式表示b 连接到a 是的。 b 是源，a 是接收器。如果在代码中完成了到a 的新连接，它将被替换。

在以下代码中，a 连接到c：

a := b
a := c

这种写法可能很奇怪，但在条件分支中设置一个默认值很有用。

例如：

a := b
when(z === true.B){
    a := c
}

默认情况下，a 将连接到b，除非z 为真。

不要忘记 Chisel 是一个 HDL 生成器。它生成硬件代码，一些关键字是纯 Scala 像 if, for, ... 而其他是硬件凿子关键字像 when, Mux, ...

然后在代码生成阶段执行第208行的for循环。并且会生成一些硬件凿when复用代码。

【讨论】：

【解决方案2】：

我强烈建议您花一些时间使用Chisel Bootcamp。它确实可以帮助您掌握 chisel 的生成器方面。

【讨论】：