We (SiFive) are slowly working towards this type of thing. There are a number of internal features (which we’re intending to make public) around memory extraction, though they may not have public Chisel APIs. There are other, public Scala FIRRTL Compiler (SFC) transforms that provide primitives for doing things like what you’re trying to do. Enumerating these:
- SiFive Memory Extraction – Take a memory and move it to the test harness so that an end user can add signals to it.
- SiFive Memory Port Addition – Drill some ports in from the top to specific memories.
- SFC Wiring Transform/Chisel’s
BoringUtils – An implementation of “soft connects” that lets a user describe sources and sinks in the design that will be wired together by the compiler.
- SFC Top Module Transform – A specialized wiring transform that will drill some signals all the way to the top for connection to FPGA logic debug units.
As may be obvious, a lot of this was demand driven. (1) and (2) are both two different ways of doing the same thing that could be potentially solved by (3) if it was generic enough. (3) is pretty generic, but has some edge cases that didn’t work for everybody. (4) is one such edge case.
Ideally, I’d like to approach this from two directions: (1) in the near term continue to drive and support the existing FIRRTL custom transform stack and (2) in the mid term work towards adding the necessary primitives (operations, attributes) necessary for these types of manipulations (e.g., resolution of soft connects, hierarchy manipulations, etc.). I think the only bad solution would be to wind up with many one-off, highly specialized transforms for different purposes.
One way of approaching this is to think about a cross-module reference (XMR) primitive that can either be lowered to actual connections or SystemVerilog hierarchical references. (I wrote up something like this in: Cross Module Reference (XMR) Primitive · Issue #933 · llvm/circt · GitHub
And I agree with John that I’d like to see this as something that is generic and lives in
hw dialect. Any expedient porting of FIRRTL annotations/transforms can then be switched to support the more generic work in
hw or other downstream dialects.