The committers listed above are authorized under a signed CLA.

• ✅ login: fabianschuiki / name: Fabian Schuiki (442ff71)

Good idea! I have been thinking how to instantiating the corresponding TestBench from DUT. I think this PR gives us a acceptable solution. I wonder if there is any related API in CIRCT to elaborate Verilog for multiple top Verilog?

Is this something that would let you drive the IOs of the module to default values / DontCare?

Is this something that would let you drive the IOs of the module to default values / DontCare?

I believe it should make that possible, see my comment about implementing ImplicitClock and ImplicitReset which requiring connecting them up in the instantiating module.

Let me think through some of the stuff @jackkoenig and @mwachs5 have been pointing out.

Basically, the idea is to have a callback/lambda/block of code executed after a module's definition becomes available such that you can instantiate the module from tests. This expressly doesn't want to know about the concrete instance that triggered the module build, and it doesn't want to be able to interact with that instance in anyway (i.e. no connecting of ports). So I don't think the block should have any Instance argument, or know about the instantiation site at all.

It's important that the callback is able to capture values from the original module body though, mainly parameters, constructor arguments, and anything else that's lying around. However, since the module is closed, you can't connect to any of the hardware or change it in any way. You can, however, inspect its types and the like. So all this does is give you the opportunity to construct additional sibling module definitions that themselves instantiate the surrounding module. I don't think this really interacts with any of things you pointed out @jackkoenig.

Maybe the name should be something like afterDefinitionAvailable, withDefinition, onceDefined, or similar, to avoid confusion?

The following is the concrete unit testing API you could build around this:

trait Testable extends RawModule {
  def unitTest(gen: => Unit): Unit = {
    val parent = this
    afterModuleBuilt {
      Definition(new RawModule with Public {
        override def desiredName = parent.desiredName + "UnitTest"
        gen
      })
    }
  }
}

@instantiable
class Adder(width: Int) extends RawModule {
  override def desiredName = f"Adder${width}"
  @public val a = IO(Input(UInt(width.W)))
  @public val b = IO(Input(UInt(width.W)))
  @public val z = IO(Output(UInt(widht.W)))
  z := a + b

  unitTest {
    val dut = Instance(this.toDefinition)
    dut.a := 1.U << (width - 1)
    dut.b := 1.U
    Assert(dut.z === 0.U, label = f"${width} bit adder should overflow")
  }
}

class Top extends RawModule {
  val a0 = Instantiate(Adder(5))
  val a1 = Instantiate(Adder(42))
}

// Expected modules:
// - Top (instantiates Adder5 and Adder42)
// - Adder5
// - Adder42
// - Adder5UnitTest (instantiates Adder5)
// - Adder42UnitTest (instantiates Adder42)

Thanks for the feedback @seldridge! I've tweaked things a bit. Should be good to go. I don't think I have permission to merge this myself though 😿