llvm / llvm/circt

Using SystemVerilog Interfaces in Other Interfaces

Open
#1,171 2 comments 0 reactions 0 assignees View on GitHub
Verilog/SystemVerilog
Dominant language
C++
Stars
2.2k
Forks
524
Avg merge
3d 2h
Merged PRs (30d)
46

Description

I've got a situation where I'd like to have one SystemVerilog interface instantiate another. I'd like to start a discussion about how we can represent nested interfaces in the IR (as this doesn't currently seem to work).

As an example, I need to represent the following (taken from #1170):
```verilog
interface sub_regBundle;
logic [15:0] b;
logic [15:0] a;
endinterface

interface View;
sub_regBundle sub_regBundle();
endinterface
```

With the current structure of `sv::InterfaceOp` there are a number of problems:

1. Each `sv::InterfaceOp` is both a symbol and has a symbol table. This complicates things where you need to define an interface member which needs to resolve a symbol outside of its scope. This _should_ be able to resolve any public symbol and may motivate removing the symbol table from an `InterfaceOp`. (Why is there a symbol table on the `InterfaceOp`?)
2. There's a bunch of missing logic related to handling this. Currently, this doesn't seem to verify correctly as [interfaces aren't handled in `hw::getBitWidth`](https://github.com/llvm/circt/blob/8e8df8f9c4ed313781c467ddc0590386756c94f2/lib/Dialect/HW/HWTypes.cpp#L92).

To work around all this, I'm resorting to using `sv::VerbatimOp` in #1170.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading sv::InterfaceOp and lib/Dialect/HW/HWTypes.cpp, especially hw::getBitWidth, to understand the current symbol-table and interface-type handling. Compare the nested-interface example in the issue with the existing verification behavior. Done means nested SystemVerilog interfaces have a defined IR representation and verify correctly without relying on sv::VerbatimOp.

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
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.