jackkoenig
commented
7 years ago I believe the solution to this is for @chick to move his interpreter implementation of this feature to Chisel. We should also probably provide the option to have a Chisel implementation of a blackbox since that would work in the interpreter and Verilator both by default.
Currently, there is support to inline files, but it's not backend-dependent. With the testers, we have both a Verilator backend (reads Verilog) and a FIRRTL interpreter backend (which doesn't understand Verilog), so it's currently not possible to have everything contained in a blackbox. Instead, we have the completely hacky, non-modular, non-composable, and non-DRY solution of adding the implementation of blackboxes into custom Driver subclasses.
One idea would be to define some stock backends in Chisel (as objects, not as strings), and have setInline take those as a parameter. Those objects could be typeclasses with the inline type (since inline Verilog would be a string, while inline FIRRTL would be a function / object).
Bonus: the Verilog backend could emit inline Verilog in a more DRY way - for example, right now we have the module name in 3 places: the BlackBox class name, the Verilog filename to be generated, and the Verilog module name emitted. A generator could automatically derive filename and create a module skeleton given the class name (and possibly IO), while the user would only need to specify the implementation / parameters.
More ideas welcome!