-
Notifications
You must be signed in to change notification settings - Fork 73
Support peek/poking FIRRTL circuits/circuits with non-Chisel IOs #2
Comments
This will also help a lot for re-using Chisel testers with post-synthesis/post-par netlists as well. |
I think that makes sense, though I do want to keep the chisel-level circuit interface API. So some kind of shim for a FIRRTL circuit would be needed to provide the interface definition for testers2. It could be manually written, or auto-generated. For post-syn/post-par, testers2 already uses a name mapping table to translate the circuit interface data structures (Chisel hardware objects) to the handle needed by the underlying tester. If the IO structure is mostly the same this should also extend to post-syn/post-par, with potentially more top-level flow options needed to select what (eg particular Verilog files / simulator) to test? |
I think at the basic level just having a name mapping table from FIRRTL/Verilog to Chisel object will go a long way. The rest can be done in a modular/agile fashion. |
@azidar Treadle can peek and poke everything since it knows nothing about chisel. So would exposing the treadle api as a superset of common api (based on chisel2 and verilator simulation api) count. |
Peeking and poking firrtl circuits directly is now supported through the |
It would be great if the tester could peek/poke FIRRTL circuits. Also, it would be nice to use it to test IOs which a FIRRTL transform added, which doesn't have a Chisel equivalent.
I'd recommend looking at FIRRTL's
CompleteTarget
class hierarchy, and hopefully use them to represent signals. We should also probably have normal Chisel references be converted to these Targets.Thoughts?
The text was updated successfully, but these errors were encountered: