Chisel3 REPL peek value is correct but expect fails in test

Question

I am using Chisel3 to build my circuit, and I have the following test

  reset()

  private val inputData = IndexedSeq.fill(ProcedureSpaceSize)(0: BigInt)
    .patch(0, Seq(63: BigInt), 1)
    .patch(1, Seq(65: BigInt), 1)
    .patch(2, Seq(98: BigInt), 1)
    .patch(3, Seq(98: BigInt), 1)
  poke(sff.io.inputDataVector, inputData)

  step(1)

  expect(sff.io.done, true)
  expect(sff.io.ret, 65) // fails

Now I keep getting fails on the second expect. However, when I try to run my circuit in REPL and use peek to look at the values of io_ret after stepping through the same procedures according to the test, I get the correct value which is 65.

My question is simply, why am I getting failure in Chisel test but can peek the right results when debugging in REPL mode? Is it not a bug, or am I doing something wrong?

EDIT: circuit code

class SFF extends Module {

  private val dataType = Integer32Bit

  // IO
  val io = IO(new Bundle {
    // INPUT
    val inputDataVector: Vec[UInt] = Input(Vec(ProcedureSpaceSize, dataType))

    // OUTPUT
    val ret: UInt = Output(dataType)
    val done: Bool = Output(Bool())
  })

  // WIRE
  val data: Vec[UInt] = Wire(Vec(ProcedureSpaceSize, dataType))
  data := io.inputDataVector
  val paramB: UInt = Wire(dataType)
  paramB := data(1)
  io.ret := DontCare

  // LOGIC
  io.done := true.B
  io.ret := paramB

}

Which REPL are you referring to? Can you share the circuit or a relevant portion of the circuit? — Chick Markley, Jun 27 '20 at 15:08

score 3 · Accepted Answer · answered Jun 28 '20 at 18:22

Here's what I think the problem is. For historical reasons poke of a vector reverses the order of elements during the poke, and that is why you are seeing the wrong value for your return. When you used the REPL you probably did your pokes discretely so they went in the expected places.

I used the "-tiv" treadle flag to see what the simulator was doing.

The Chisel development team is planning on adding Vec literals which should prevent this in the future.

I'd also recommend trying ChiselTest, it's a more modern version of a unit tester. It does not have a poke for Vec types which would protect you against this error. When Vec literals are implemented they will be available in ChiselTest, probably not in iotesters.

Interesting. I reversed the input vector, and it indeed worked! I tried the newest Chisel test vector literal, but I just couldn't get it to work for some reason; namely, I couldn't get to use `.Lit()` on my own datatypes despite that it works perfectly on official examples. I think I will just live with the reverse Seq trick for now. — apen, Jun 29 '20 at 21:12

Chisel3 REPL peek value is correct but expect fails in test

1 Answers1