Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add IntermediateBackend for generating verilog testbenches #138

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

grebe
Copy link
Contributor

@grebe grebe commented Apr 11, 2017

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
Copy link
Contributor

@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
Copy link
Contributor

ducky64 commented Apr 11, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants