如何理解凿子语言的节拍?

Question

我正在学习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为true时，上述代码是否同时赋值?

1. 例如当前uop为fmul, in_uop= fadd。当io.in_uop。有效时，上述代码将同时执行。但是有一个问题。

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为true，此时发送槽将输入fadd信息。同时，原fmul信息仍将输出到下一个相关信号中。这应该是不合理的。问题发生在哪里?

2. 用于第207行For循环。我还是觉得很难理解。for循环会在一个节拍内执行吗?例如，如果我使用For循环遍历队列，那么For循环何时结束?

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

Answer 1

1. first

a := b表示b连接到a是。b是源，a是汇。如果到a的新连接在代码之后完成，它将被替换。

在下面的代码中，a连接到c:

a := b
a := c

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

例如:

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

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

第二

不要忘记Chisel是一个HDL生成器． 它生成硬件代码，一些关键字是纯Scala的，如if,for，…等为硬件凿关键字，如when、Mux、…

则在代码生成阶段执行第208行中的for循环。并将生成一些硬件凿子whenmux代码。

Answer 2

我强烈建议你花点时间在Chisel训练营。它可以真正帮助你掌握chisel的生成器方面。