Dump verilog testbench

[ShuyunJia]

Are there any plans for dumping verilog testbench? It is always needed for post-simulation. I think the VerilogTbDump implementation in https://github.com/ucb-bar/dsptools/blob/master/src/main/scala/dsptools/tester/VerilogTbDump.scala is good enough. Any plans to include such dsptools in the testers packages?

[edwardcwang]

See #60. In general, translating arbitrary Scala code, which is what a testers2 program is, to Verilog is not really feasible or desirable.

[ducky64]

To expand on that answer a bit more:

• Testbenches written in testers2 are nonsynthesizable, you're essentially writing a Scala program that interfaces with a simulator through peek and poke operations. So generating a equivalent Verilog testbench in the general case is somewhere between impossible and very difficult.
• If you just need Verilator simulating directly Chisel elaborated RTL, that is currently supported. See example test cases at https://github.com/ucb-bar/chisel-testers2/blob/master/src/test/scala/chisel3/experimental/tests/VerilatorBasicTests.scala
• If you need Verilator on your post-syn, that's on the roadmap (see #60). I don't have an ETA.
• If your test reduces down to basically a static testvector, that is, the test control flow does not depend on the circuit state, it is theoretically possible to dump that testvector to a Verilog nonsynthesizable harness. Adding primitives like waiting for a signal state might allow a small amount of dynamic control for common operations, like waiting on a ready signal. But this isn't on the roadmap, since I think #60 gets you most of the way there?
  • More interesting than having everything generate down into pure Verilog might be synthesizing test cases onto a FPGA without needing Scala (and a PC host, with associated potentially slow communications) in the loop, for very long test cases. But this is also not on the roadmap, so maybe wayyy future work.
• Otherwise I'd be interested in hearing about your use case and discussing potential solutions.

[ShuyunJia]

For post-syn simulation without timing check, I think the blackbox solution in #60 is good enough.

For post-simulation with sdf annotation, however, I have to switch to vcs or ncsim for timing check. It's when a verilog testbench is needed. Usually we don't need all the testcases for post-timing simulation, just the basic ones covering timing paths. From my experience in commercial chips development, static vector test cases are ok for a post-timing simulation. That's why I think a straighforward dumping to nonsynthesizable verilog would be helpful.

[ducky64]

That makes sense. Architecture-wise, it should be possible to create a backend that dumps poke and delays, and it was a theoretical consideration during the design phase. I don't have the bandwidth to build it in the near future, but if you'd like to build it, we can discuss how to architect such a system to integrate with everything else.

Alternatively, since VCD dumping is a currently existing feature, would it be simpler to build a testharness by parsing VCD dumps?

Also, it's worth noting that the testbench semantics are zero-delay. I don't know if that complicates integration with timing checks,

[ShuyunJia]

I prefer a straightforward verilog dumping since it is much more intuitive. When annotated with sdf, vcs would know how to specify and check the timing inside I submit a draft pr #95, which is similiar to the implementation in https://github.com/ucb-bar/dsptools. In this pr, the verilog is dumped line-by-line with the peek-poke execution order. The fork-join is ignored here. When several threads are available, the dumped vector is in the actual execution order of these threads. The difficult part is to translate the while keyword, I have to introduce a new method called waitAndStep here. Maybe you can give suggestions on it.