Feature request: Extend DecoupledDriver with Enqueue/DequeueEmpty

[erlingrj]

Feature request: Extend DecoupledDriver with Enqueue/DequeueEmpty

[ducky64]

Ah. So Decoupled provides a default constructor that fills in the EmptyBundle for you.

For now, see if the above works: myDecoupled.enqueueNow(new EmptyBundle().Lit())

In the longer term, since this empty-Decoupled is part of the chisel API, it might make some sense to add support for it in ChiselTest. I'm not sure if we can match on DecoupledIO[EmptyBundle] to define a specialized implicit, or if we want to add something like an empty enqueue that would rely on a runtime check.

[erlingrj]

Thanks again. It turned out the correct syntax was

myDecoupled.enqueueNow(chiselTypeOf(myDecoupled.bits))

[ducky64]

What does your Decoupled interface look like? It has to take some data type, right - even if that type is an empty Bundle or 0-wide integer (not sure if the latter is allowed)? Can you call enqueue/dequeue, passing in that data type?

I'd not be a huge fam of having enqueueEmpty or dequeueEmpty because it wouldn't be valid for most Decoupled interfaces, and especially if the compositional approach works, like myDecoupled.enqueueNow(EmptyBundle().Lit()).

[erlingrj]

No, I dont specify any data type. Like this: https://scastie.scala-lang.org/dmjRHxryTYW5Sif9HiJHiA I was actually surprised that you could have an empty Decoupled signal.

[erlingrj]

Thanks for your help. I tried your suggestion, but EmptyBundle is a private class inside Decoupled, so not available. I made my own copy of it, but that gave a "Record type mismatch" error at the "x.bits.poke(data)" statement in the enqueue driver.

[ducky64]

I see. How about this?

myDecoupled.enqueueNow(chiselTypeOf(myDecoupled.bits).Lit())