Allow peeking internal signals

[ducky64]

Resolution from chisel-dev 2/8: should be able to peek internal signals, optionally needing an annotation to avoid DCE

[sequencer]

I have such problem these days, and I got an idea(a not pretty way to solve this), but technologically, it works, I wonder if there is any elegant way to do so?

At first, I tried to bore signals directly to testFn, it says

Error: Not in a UserModule. Likely cause: Missed Module() wrap, bare chisel API call, or attempting to construct hardware inside a BlackBox.

looks like I cannot create a NamedComponent during the test, it sounds reasonable. Then I choose using a wrapper to work around.

for example, here is my dut

class Dut extends MultiIOModule {
  val internalWire = WireDefault(true.B)
}

I need to create another DutWrapper like this,

class DutWrapper extends MultiIOModule {
  val core = Module(new Dut)
  val internalWire = IO(Output(core.internalWire))
  // and bore them together:
  BoringUtils.bore(internalWire, core.internalWire)
}

Then use DutWrapper as dut in testFn

test(new DutWrapper) { dut =>
  val result = dut.internalWire.peek()
}

This is the only method I came up with to peek a internal signal without altering Dut.

[ducky64]

Yeah, so the test function runs on fully elaborated hardware, so you can't make modifications to the hardware during test execution.

You might be able to wrap your DUT in a anonymous top level module in test that you can bore through, while also passing through the top-level IOs.

In the long(er) term I think the solution is just to add internal peek support, though I think there were some technical hurdles like naming.

[sequencer]

Currently idea to do this implementation:

1. annotate signal required to be peek/forced.
2. use firrtl transform to add /**verilator public**/ attributes, which need freechipsproject/firrtl#1172
3. add chiseltester API to access these public signals.