Skip to content

[hw] Add container op #8704

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

seldridge
Copy link
Member

@seldridge seldridge commented Jul 14, 2025

Add a new hw.container op. This is intended to be a generic container
of hardware. Critically, this exists to enable the checking of ops that
are users of inner symbol tables. This is shown with the one error test
case that shows validation of a hw.hierpath op with an invalid inner
symbol use. (This will not be checked if a builtin.module is used.)

Note: this is intended to be temporarily backwards-compatible with existing operations. This is done by allowing hw.module and friends to have a parent that is either a builtin.module or a hw.container. As long as there is buy-in on this approach, I will then go about updating all tests, migrating things over, and requiring that hw.module and friends have a hw.container parent.

Add a new `hw.container` op.  This is intended to be a generic container
of hardware.  Critically, this exists to enable the checking of ops that
are users of inner symbol tables.  This is shown with the one error test
case that shows validation of a `hw.hierpath` op with an invalid inner
symbol use.  (This will not be checked if a `builtin.module` is used.)

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
@seldridge seldridge requested a review from darthscsi as a code owner July 14, 2025 21:27
@seldridge seldridge requested a review from dtzSiFive July 14, 2025 21:27
@uenoku
Copy link
Member

uenoku commented Jul 15, 2025

For temporary migration, are you going to change ExportVerilog etc to allow both container op and builtin.module? In that case we will need to either make passes op-agnostic or tweak canScheduleOn manually a lot of places.

@seldridge
Copy link
Member Author

For temporary migration, are you going to change ExportVerilog etc to allow both container op and builtin.module?

I had thought that something like this could work, but didn't know the particulars of how to do it.

That said, Will did almost a full migration a while ago (main...dtzSiFive:circt:feature/hw-design-op) and that touched a lot of files, but wasn't conceptually that big of a diff. So, maybe we just get consensus and then do a hard switch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants