Hello BCR maintainers, modules (rules_verilator) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

Hello BCR maintainers, modules without existing maintainers (rules_verilog) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

Hi @fmeum
Could you please review this PR at your convenience, thank you 😃

@fmeum You may need to start the CI. I do not have that permission.

Thank you

Sorry for only chiming in now, but I would have liked to see some more context in this PR, and possibly a different module name. The github issue in rules_verilator doesn't really inform us about:

• How this is different from https://github.com/periareon/rules_verilog
• How this is different from https://github.com/hdl/bazel_rules_hdl (which from my bystander perspective looks like the more commonly maintained and active repository for RTL design and verification flows)
  • It seems bazel_rules_hdl is not on the BCR yet @QuantamHD
• Why your repository basically only has one rule and a couple of providers

The name rules_verilog sounds very authoritative and over-promises on the functionality provided. Given the limited scope of the Starlark code, I think this could have stayed as a special "implementation detail"-type rule in rules_verilator.

Perhaps too late now, but there's a blurb in the BCR maintainer doc that would have applied to this PR.

Hi @ted-xie please check hw-bzl/rules_verilog#1 , hw-bzl/rules_verilog#2 , agoessling/rules_verilog#1 and hdl/bazel_rules_hdl#428 (comment) for more details

Why your repository basically only has one rule and a couple of providers

This design is intentional and aligns with the Bzlmod's philosophy of high modularity and decoupling. The primary goal of rules_verilog is to provide only the most foundational Verilog interfaces (e.g., verilog_library). This allows downstream rulesets, such as rules_verilator or rules_vivado, to easily consume them without introducing unnecessary overhead.

I believe that a massive, monolithic, "kitchen-sink" approach like the old rules_hdl is largely an anti-pattern and highly unsuitable in the bzlmod era.

How this is different from https://github.com/hdl/bazel_rules_hdl (which from my bystander perspective looks like the more commonly maintained and active repository for RTL design and verification flows)

Since 2023, many community members (myself included) have made numerous attempts to migrate rules_hdl to Bzlmod so it could be published to the BCR (e.g., hdl/bazel_rules_hdl#428, hdl/bazel_rules_hdl#336, google/heir#332, hdl/bazel_rules_hdl#210, hdl/bazel_rules_hdl#405 ). Unfortunately, these efforts have faced significant friction and stalled within the rules_hdl repository.

More importantly, as I mentioned above, the Bzlmod paradigm strongly emphasizes modularity and decoupling. A massive, monolithic project like rules_hdl is simply ill-suited to be packaged as a single BCR module (check The-OpenROAD-Project/OpenROAD#7647 (reply in thread)).