Home > other >  How to understand the beat in chisel language?
How to understand the beat in chisel language?

Time:09-23

I am studying the design of riscv-Boom. It is designed with chisel. When I read its source code, I always cannot understand when the signals in these circuits will be obtained. Normal programs are executed one by one. But hardware languages like chisel are not.

https://github.com/riscv-boom/riscv-boom/blob/master/src/main/scala/exu/issue-units/issue-slot.scala For example, the link above is the source code of Issue-slot in Boom.

 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

This is some code in the IssueSlot class in the link above. For the chisel hardware language, these := should mean that they are connected together by wires. So do these signals change at the same time? For example, when io.in_uop.valid is true, does the above code assign values at the same time?

  1. For example, the current uop is fmul, and in_uop= is fadd. When io.in_uop.valid, the above code will be executed at the same time. But there is a problem.
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

When io.in_uop.valid is true, the transmit slot at this time will be input fadd information. At the same time, the original fmul information will still be output to next-related signals. This should be unreasonable. Where does the problem occur?

  1. For the for loop of line 207. I still find it difficult to understand. Will the for loop be executed in one beat? For example, if I use a for loop to traverse a queue, when did the for loop finish?

If anyone is willing to answer me, I would be extremely grateful!

CodePudding user response:

  1. first

The a := b expression mean that b is connected to a yes. b is the source and a the sink. If a new connection to a is done after in the code, it will be replaced.

In the following code, a is connected to c:

a := b
a := c

This writing could be strange but it's usefull to set a default value in conditionnal branch.

For example :

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

By default, a will be connected to b except when z is true.

  1. second

Do not forget that Chisel is an HDL generator. It generate hardware code, some keywords are pure Scala like if, for, ... and other are hardware chisel keyword like when, Mux, ...

Then the for loop in line 208 is executed at the code generation stage. And it will generate some hardware chisel when mux code.

CodePudding user response:

I'd highly recommend you spend some time with the Chisel Bootcamp. It can really help you grasp the generator aspects of chisel.

  • Related