dsptools
dsptools copied to clipboard
ucb-bar
Add new ExecutionOptions, Logging
This code in DspTester prints messages every time. Ideally, dsptools would use the same logging infrastructure as everything else.
@stevobailey has an issue where DspPoke messages (among other things) fills up travis logs very quickly.
I think we should wait for /ucb-bar/chisel-testers/pull/62 to get merged and then use the existing _verbose flag in the chisel_testers to control println's in DspTester
Is _verbose meant to be visible to subclasses? If so, that sounds like the right thing to do.
It is visible, I am not sure if it is supposed to be or not. But I think we should use it for now
@chick can you explain why/when you should be using dsptools.Driver.executeFirrtlRepl instead of chisel3.iotesters.Driver.execute?
Also, in general, better documentation on when to use what Drivers and how to supply arguments to say, FIRRTL, from your project, would be extremely useful.
It kind of bothers me that something you simulate might not be the thing you actually end up generating Verilog for [sbt run vs. sbt test] if you have multiple drivers and don't pass in the right options to both...
Say, in one version, FIRRTL does a pass that fundamentally breaks the Verilog, but with sbt test, you don't actually run one of the optional passes.
@shunshou The executeRepl launches the firrtl interpreter repl (shell) that let's one interactively peek poke and fiddle with the circuit. I use it for certain kinds of debugging both of circuits and of the interpreter itself. It is somewhat orthogonal to the iotesters.Driver.execute, which runs a PeekPoke tester harness on the device under test. Although the repl does provide for script files of repl commands and/or vcd files to drive the dut. I can show it too you at hacking today if you are interested
Ok I missed your previous post. Is there now documentation listing particular options you can mess with and pass down all the way to FIRRTL? Say, how to run the SRAM pass from Chisel, etc. I'd like one concrete example that explains all possible ways people can setup the drivers.
@shunshou I agree the Driver and logging interface need documentation, but I think that is an issue far outside the scope of this issue and project. There is now a standard way of adding execution options (and log levels, I guess), but there is not a standard way of documenting and exposing them. This needs to happen.
@chick, do you think this should become a firrtl issue? chisel3? I'm not really sure where it belongs. When we come up with where we want to file a new issue, we can close this one- the original problem is long gone.
I think it should be an issue at all levels in which the execution options are used. Since there are custom DSP driver execution options, you should describe those and have links to explanations of Chisel/FIRRTL options in their respective repos, since the DSP driver extends everything down to whatever base thing from Chisel/FIRRTL land... I'd like to see that happen ASAP.
@chick can you or someone else write up an example of the "one true" methodology for setting up with various execution options? I'll probably just end up writing some messy, pieced together thing if there isn't some nice formula, and I really don't want to keep rewriting code for the sake of following right way to write something that isn't explicitly expressed anywhere... I'm just hesitant to start porting from Chisel2 if Chisel3 syntax isn't 100% formalized... (starting with CORDIC)
I'm also ok writing a hacked example and having someone clean it up to look the way it should work to use as a golden model...
Actually, turns out I posted an issue re: documentation for this (before executeoptions was created?) here: https://github.com/ucb-bar/chisel3/issues/309 [I just never got any responses...]