Add IntermediateBackend for generating verilog testbenches

[grebe]

This is a rough stab at getting the basic functionality to generate a (in my case verilog) testbench via the chisel testers API.

The thing I wanted to do was to run the jtag chisel tests I had written on the top level craft2-chip, which is not easy to do with the chisel testers API for many reasons (makefile-based build system doing some magic with external IP, wanting to use ncsim, and more). What I wanted was something like @shunshou's nice tester mixin that dumps a verilog version of the test you just ran, but it wasn't convenient to use because of the tests I was using from @ducky64 using a different testing API.

I ended up adding a backend that generates an intermediate representation of the test you just ran and then (in a separate repo) an application specific "compiler" (really just a handlebars template based on Angie's VerilogTbDump) for the IR to a verilog testbench appropriate for my application. The IR is really simple- poke, expect, step, and reset. I want to plant my flag on the names birrtl or tirrtl (behavioral or testing intermediate representation...) on the off chance that this becomes a thing

Do you guys think this idea has merit? It sure was handy for me. I was thinking of adding new backends that extend Verilator with Intermediate or VCS with Intermediate that runs the test and then adds the event to the queue (also, peeks would not throw an exception and would add expects to the event queue). I'm not necessarily a fan of the way I've written the code- maybe it would be better to have an option that every backend respects rather than new backends that work the same but add this new functionality. In that case I'd like to have a DoNothing backend for situations where for whatever reason it is hard to get a chisel testers backend running your circuit.

Sorry for writing a book!

[shunshou]

@ducky64 all the more reason to keep something like peek/poke/expect functionality imo. Glad the principle of my thing was useful -- sure saved me a lot of pain debugging stuff beforehand (b/c let's be serious, rocket-chip-style Makefile etc. isn't super friendly for testing simple designs). I'd like at some point to convert my thing into Handlebars too, but if you think there's a more "unified" approach, then I'd be totally down for something like that.

[ducky64]

Yeah, this makes sense, though some of the ideas in the testers unification supersede this (such as synthesizing pokes / checks into a state machine, rather than only as a sequential testvector).

Ultimately, I think this is a use case worth keeping in mind, but I want to see one unified tester API (at least for the basic stuff, which this would count as). I know that CRAFT is taping out soon and needs an immediate solution, but I hope that chipsalliance/chisel#551 will be the future, precisely to avoid the interoperability issues you noted.