llvm / llvm/circt

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

Open
#10,131 3 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
2.2k
Forks
524
Avg merge
3d 2h
Merged PRs (30d)
46

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by tracing the FIRRTL-to-HW/SV lowering for attach, print-related operations, simulation interventions, cross-module references, and verification operations, then review the sim and verif dialects. Done means the listed semantics remain in HW, sim, or verif until their final backend lowering, without unnecessary SV operations for non-SV backends.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.