Feature request: Add SystemVerilog support #843

Description

I’d like to contribute first-class SystemVerilog support to AFT. I’d like to align on the architecture and feature scope first.

The proposal is to extend AFT’s existing tools with complementary source-structural and compiler-backed views of HDL projects.

Architecture

Two complementary frontends

• Use tree-sitter-systemverilog for written-source structure: symbols, outlines, source zoom, structural search, and AST-based edits. These capabilities should remain available without a configured or successfully compiling design.
• Use Slang, through Rust bindings, for configured-design semantics: resolved declarations, types, references, package imports, procedural calls, argument bindings, and elaborated hierarchy.

Tree-sitter describes the source as written; Slang explains its meaning within a selected build. Physical declarations and elaborated instances should remain distinct in the tool results.

A shared compiler service in the Rust engine

Keep compiler integration in the engine so OpenCode, Pi, standalone, and Subc share the same behavior. Run native Slang compilations in a supervised helper process and return bounded, owned compiler facts rather than sharing native compiler objects across engine threads.

Analyze captured source snapshots, with filelists, includes, and library loading mediated by AFT’s file-access policy. Cache analysis per checkout and selected build, invalidating it when source files, configuration, or dependencies change.

Explicit build context

Support named build profiles containing source files and filelists, include directories, macro definitions, library files/directories, top modules, and compiler options. Compiler-backed tools should consistently use the selected profile, while structural tools remain independent of build configuration.

Complementary LSP integration

Integrate slang-server through AFT’s existing LSP infrastructure for diagnostics, definition/reference navigation, and rename proposals. Use the compiler service for captured build analysis and validation of proposed changes.

Features

Compilation acceptance and binding preservation are different checks: an edit can compile while changing which declaration a name refers to. Tools should make that distinction clear and report partial coverage when errors or unsupported constructs prevent a complete answer.

Integration approach

Extend the existing AFT tools rather than introduce a separate HDL tool suite. Keep harness adapters thin and preserve shared preview, backup, undo, cancellation, and path-policy behavior.

Would this dual-frontend architecture fit AFT’s direction? If so, I’d propose incremental contributions: structural support and LSP integration, then the shared compiler service and semantic tools, followed by validated editing and refactoring.

Use case

SystemVerilog projects commonly depend on filelists, include paths, macros, packages, libraries, and selected top-level modules. Understanding a file in isolation is often insufficient to resolve a reference or determine the effect of an edit.

This would let coding agents use AFT’s existing workflow to:

• Explore source structure immediately, even before the design builds successfully.
• Resolve references and procedural calls using the actual build context instead of matching names alone.
• Inspect elaborated instances while retaining links to their physical source definitions.
• Follow procedural data flow across assignments and function/task boundaries.
• Edit imports, rename declarations, and perform supported refactors with compiler-backed checks before applying changes.
• Validate coordinated edits against the selected design and use the existing preview/undo workflow.

Keeping these capabilities in AFT’s shared engine would make them available consistently across supported harnesses, including mixed-language repositories containing HDL alongside software and build tooling.