[FIRRTLToHW] Reducing SV dialect leakage into HW dialect for non-SV backends

[nanjo712]

While simulating large-scale processors using Arcilator, I've observed that the hw targets generated by firtool are heavily interleaved with SystemVerilog (sv) operations. While this is natural for the SystemVerilog backend, it creates significant overhead for non-SV backends.

As discussed in previous PRs (and following feedback from @fabianschuiki ), attempting to handle these SV ops within Arcilator leads to an unnecessarily bloated processing pipeline. Since CIRCT already provides the sim and verif dialects, we should leverage them to decouple simulation/verification semantics from the structural hardware description.

I have drafted a plan as part of the migration.

---

1. firrtl.attach -> hw.attach (or equivalent)

Currently, firrtl.attach often lowers directly to sv.alias or a complex all-pairs sv.assign matrix (wrapped in ifdef SYNTHESIS).

• Proposed Change: Introduce a structural hw.attach op.
• Keep the "connectivity intent" in the hw dialect. Move the decision of whether to emit an alias, an assign matrix, or a verbatim error into the HW-to-SV lowering phase.

2. Print-related Ops (printf, fprintf, fflush)

These currently generate SV always blocks during lowering.

• Proposed Change: Lower these to the sim dialect.
• Additions to sim Dialect:
  • Support output stream specifiers (stdout vs. file descriptors) in sim.print.
  • Add sim.get_file to manage file descriptors via filename mapping.
  • Add sim.fflush for stream synchronization.
• Only lower to SV always blocks during the final Sim-to-SV phase.

3. Simulation Interventions (ref.force, ref.release)

These are purely simulation-level constructs and currently "leak" into SV always blocks early.

• Proposed Change: Lower to sim.force and sim.release.
• These ops need support for Cross-Module References.

4. Cross-Module References (xmr.ref, xmr.deref)

• Proposed Change: Standardize on sim.xmr.ref (or a similar intrinsic) referencing an hw.hierpath symbol. This provides a unified way for backends to track remote signals.

5. Verification Ops (assert, assume, cover)

Currently, these generate SV-specific logic (e.g., sv.always, sv.if) depending on the "flavor".

• Uniformly lower these to verif.clocked_assert/assume/cover.
• Addition: Ensure message/format string support is fully integrated into the verif dialect ops.

---

I intend to follow up on this work incrementally. This is not exhaustive for now and I would love to hear feedback on the proposed change.

[fabianschuiki]

Very cool! I typed up a response to one of your PRs and then realized that you have already written up this excellent issue here 😁

[fabianschuiki]

Your list is excellent! My recommendation would be:

1. Start with assert/assume/cover verif ops, and FIRRTL's print/stop mechanisms. These should be fairly standalone, and for a lot of them we already have equivalent Verif or Sim dialect ops.
2. File print ops might also be fairly straightforward to implement. You'll have to extend the Sim dialect with a few of these, which would be very valuable! The circt-verilog frontend also needs to be able to represent $fopen and similar calls in the IR; if you add things to the Sim dialect, we can emit your ops directly from the Verilog frontend 🥳.
3. Tackle XMRs and force/release separately afterwards. These will require a representation for FIRRTL probes in HW, probably as a ref/probe port. This will be an absolutely fantastic addition to HW, and there are many use cases that will benefit from it. It just needs some careful thinking, because SystemVerilog limits us in the hierarchical names that it can represent, which means the !hw.probe or !hw.ref type we create to carry references across ports will have to be very carefully crafted such that you can't describe refs in the IR that SystemVerilog cannot represent. @dtzSiFive has spent a lot of time thinking about this in FIRRTL -- he'll have a few excellent ideas and knows where all the difficult challenges are.
4. firrtl.attach might be the last thing to tackle, or skip entirely. The problem with hw.inout and attach is that they completely break the SSA paradigm that HW/Comb/Seq is built around. This feels more like a wire/net declaration and then an op to assign/connect to it. That's what the SV dialect has been doing, and it's also what makes the IR annoying to analyze and reason about. We might need a separate dialect to capture the "analog" part of a circuit, like wires and drivers.

I think the main challenge will be to switch over to core dialect ops, and keep the weird FIRRTL quirks (like configuration macros) out of the Sim and Verif dialect ops. (Or create FIRRTL-specific flavors of Sim dialect ops that contain the FIRRTL weirdness -- we do this in seq.firreg and seq.firmem for example.) Some things like the assert/print enable and condition macros you could move to a later pass in the pipeline: emit the Verif/Sim ops directly from FIRRTL, and then add an option to a pass like SimToSV to not only convert to SV ops, but also add the FIRRTL-specific enable macros. That would give you a clean HW/Comb/Seq/Sim/Verif interface after FIRRTL, and we'd still get all the FIRRTL quirks added at a later stage.

I'm also pretty sure that some of the things we do with macros at the moment could actually be expressed as an HW dialect op which models optionality: a list of body regions/blocks and a config option that decides which one is active. @uenoku has been poking at that in the past.

[uenoku]

Start with assert/assume/cover verif ops

I rather think Verif is hardest among this list unless we allow to introduce FIRRTL's verification flavors to core dialects (which I really don't want to introduce). We(SiFive) once tried to unify different flavors to SVA internally, but it didn't went well because macro based global assertion control (ASSERT_COND etc) is actually used. So I recommend from Sim printf/fprintf (as you already did). Sim fprintf alone requires fair amount of design work because of the open problem around side effecting ordering as @fzi-hielscher mentioned.