Search code examples
fpgachiseldigital-logic

Chisel3 REPL peek value is correct but expect fails in test


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

}

Solution

  • 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.