How to avoid "divergent poking / peeking threads" when use fork/join

[Wolf-Tungsten]

I implemented an arbiter with 4 request ports and 4 response ports. All these request and response ports are in decoupled style. When a client want to perform some critical action, it has to request on a specified request port and wait for an ack from response port.

As this arbiter works like a mutex lock, I would like to test it in a multi-thread style, so I wrote the following codes:

//.....
var threadHandle = fork{}
for (i <- 0 until Config.LAUNCH_WIDTH) {
  threadHandle = threadHandle.fork {
    val idx = i
    for (j <- 0 until TESTNUM) {
      dut.clock.step(1)
      // launch a request
      dut.io.port(idx).request.valid.poke(true.B)
      while (!dut.io.port(idx).request.ready.peek().litToBoolean) {
        // wait until request is accepted
        dut.clock.step(1)
      }
      dut.io.port(idx).request.valid.poke(false.B)
      
			// wait for response
      dut.io.port(idx).response.ready.poke(false.B)
      while (!dut.io.port(idx).response.valid.peek().litToBoolean) {
        dut.clock.step(1)
      }
      dut.clock.step(1)
      dut.io.port(idx).response.ready.poke(false.B)

    }
  }
}
threadHandle.join()
}

And then, unfortunately, I got a:

chiseltest.ThreadOrderDependentException: Bool(IO io_port_0_request_valid in Arbiter) -> Bool(IO io_port_3_request_ready in Arbiter): Divergent poking / peeking threads

So, what's wrong here?

[sequencer]

Could you please provide a piece of reproducible code?
If your code is not open sourced, just copy & paste your code to https://scastie.scala-lang.org, and we can help you debugging it.

[Wolf-Tungsten]

I present a reproducible example here:https://github.com/Wolf-Tungsten/divergent_poking_peeking_threads

You can run sbt test to get the exception.

Thanks!

[ducky64]

Possible cause (without looking at the details of your example or test case): ChiselTest doesn't allow combinational peek-after-poke operations between threads. This applies for peek-after-poke on the same signal, and signals that are combinationally dependent. From the error message, it appears one thread is poking io_port_0_request_valid and another is peeking io_port_3_request_ready, and there may be a combinational path between the two.

Here's the check that generates that error message.

[Wolf-Tungsten]

I just generated the Verilog of this module, and I got:

/**...**/
  wire  _GEN_1 = 2'h1 == ptr_r ? io_port_1_request_valid : io_port_0_request_valid; // @[Arbiter.scala 30:47 Arbiter.scala 30:47]
  wire  _GEN_2 = 2'h2 == ptr_r ? io_port_2_request_valid : _GEN_1; // @[Arbiter.scala 30:47 Arbiter.scala 30:47]
  wire  _GEN_3 = 2'h3 == ptr_r ? io_port_3_request_valid : _GEN_2; // @[Arbiter.scala 30:47 Arbiter.scala 30:47]
/**...**/
  wire  _GEN_11 = _GEN_3 & _GEN_7; // @[Arbiter.scala 30:47 Arbiter.scala 15:34]
/**...**/
 wire  _GEN_33 = _T_1 & _GEN_11; // @[Conditional.scala 39:67 Arbiter.scala 15:34]
/**...**/
  assign io_port_3_request_ready = _T ? 1'h0 : _GEN_33; // @[Conditional.scala 40:58 Arbiter.scala 15:34]

Do these codes mean that there is a combinational path between io_port_0_request_valid-> _GEN_1->_GEN_2-> _GEN_3->_GEN_11->_GEN_33->io_port_3_request_ready?