Bzlmod porting.

[lromor]

Hi, I ported the dependencies of this project and this project to bzlmod at:
https://github.com/amorphic-io/OpenROAD/tree/bzlmodify

Most of the dependencies needs to be overriden but I think it could be a good starting point to simplify the import of OpenROAD (and rules_hdl) in other bazel projects.

I would love to merge these changes in the respective transitive and direct deps repos and/or in BCR but it requires some effort.

[oharboe]

Interesting!

Normally I would expect a pull request for a branch such as this.

Are you planning to make one or more pull requests?

[maliberty]

I would like to see a PR as well. I see you also have some changes for new flags that would be good to separate out. Is that something you are willing to do?

[lromor]

Hi @oharboe , @maliberty ! Yes, I would love to see this merged. Right now as you can see there's some work scattered on many different projects.

I would love to hear your opinion on how to proceed.

I see two different routes:

1. PR with MODULE overrides for dependencies not yet merged in BCR pointing to my repos.
2. Define a roadmap to merge the direct/transitive deps first and then open a PR here.

What do you think?
Adding @hzeller and @mithro here in case they are interested.

[oharboe]

If possible, create single concern independent PRs so that we can have as much go in as possible and then worry about the bigger fish separately...

OpenROAD has traditionally forked git projects where needed for stability of dependencies. I'm thinking that if you create the PR with your own repositories, they can be forked by the OpenROAD project, if needed, while we wait for things to trickle int BCR.

So my thinking is to go with 1. above and then whittle away at things, forking dependencies as needed, and switch to BCR when it becomes available.

Getting rid of WORKSPACE would be a big boon. OpenROAD itself can then be used from another MODULE.bazel...

[lromor]

Great! I'll do my best to prepare a PR this weekend.

[maliberty]

Do you have a list of open PRs to BCR? @QuantamHD might be able to help move them through. If we can do that quickly it would avoid the two-step of forking and then updating to BCR later.

[lromor]

I do not have any PR open in BCR.

• tcl: bzlmod.
• swig: exists in bcr, added lib_tcl.
• llvm-project: bumped version + bzlified openmp runtime.
• rules_cc: nix fix.
• abc: bzlmod.
• ncurses: added a fix for nixos. Recently a patch might already fix this.
• lemon: bzlmod.

I think I can start with tcl.

[lromor]

I decided to proceed in the following way.

1. I'm working on a tool to simplify the bcr modules generation process made in rust. It iterates through my branch patches, parses the summary and tries to generate a compliant bcr module.
2. Update my bcr fork so you can start using my overlayed modules without MODULE overrides.
3. Open a PR against OpenRoad to include the changes I made to the project.
4. Open a PR against bazel-central-registry to add/bump the new modules.

Today I mostly worked on 1.

[maliberty]

Any updates?

[lromor]

I managed to get a clean set of patches and fixed an issue for llvm-project that would not build when using ld.gold. All tests seem to be passing now.

[lromor]

Someone independently just added tcl: https://github.com/bazelbuild/bazel-central-registry/pull/5369/files

[MrAMS]

maybe we do not need llvm-project use toolchains_llvm instead? check my OpenRoad fork. here? Although I find that a single ./external/toolchains_llvm++llvm+llvm_toolchain_llvm eats 11GB 😢

[lromor]

llvm is required, I had to package openmp. Maybe openmp runtime could be split into a separate module but I'm not sure what the linking consequences will be.

[MrAMS]

llvm is required

However, why haven't we encountered any issues with the current build? Is it because OpenMP is disabled?

[lromor]

Hey there! Although I had a very complicated set of months and I couldn't get back to this, looks like someone moved towards that!
Big thanks to @MrAMS!
hdl/bazel_rules_hdl#428

[MrAMS]

As I summarized in bazel_rules_hdl/pull/428#issuecomment-3650156939, I have merged OpenROAD and its dependencies with the latest upstream. Should I submit a PR to OpenROAD for this? I would love to hear your suggestions.

[MrAMS]

Alternatively, is there anything else I can assist with? If possible, could you provide a more clear todo list? This would establish a clear goal for anyone interested in collaborating.

[maliberty]

We have forks for abc & sta. I'd like to see PRs to those repos first rather than point at your copies. Then we can PR OR to use those.

[MrAMS]

Copy that. I will solve the bazel-orfs first as it seems much more easy.

[oharboe]

This may be a non-sequitor, but I just want to point out that OpenROAD has not emptied WORKSPACE yet either... https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/WORKSPACE

[MrAMS]

you are right, I will check ORFS flow later

[oharboe]

@MrAMS Perhaps you'll find this https://github.com/Pinata-Consulting/RegFileStudy example interesting. It uses Chisel+bazel-orfs to plot characteristics of flows and designs, such as scaling register files, effects of retiming on multiplication and floating point units, etc.

Also, there are OpenROAD test cases that uses bazel-orfs, including Chisel, simulation, power based on .saif files, eqy_test, etc. https://github.com/Pinata-Consulting/OpenROAD/tree/master/test/orfs

[MrAMS]

@oharboe Oh yes, thank you for sharing! Did you mean https://github.com/The-OpenROAD-Project/RegFileStudy? The link Pinata-Consulting/RegFileStudy seems to return a 404.

This project looks quite interesting—I will dig into it. And try running the OpenROAD test cases when I have some free time.

[MrAMS]

After carefully studying your RegFileStudy project, I must say it is a truly elegant and brilliant solution. I gained a lot of insight from it and plan to fully adopt your approach. Thank you so much for sharing this!

[oharboe]

Glad you like it!

[oharboe]

I'm curious: I always thought rules_hdl is a pre-bazel bcr vestige and that the path fowrard was to break out rules_hdl and contribute to bazel bcr and leave rules_hdl alone as the pre-bazel bcr legacy it is?

[oharboe]

Oh, regarding Verilator, I seem to have overlooked that your rules_verilator points to rules_hdl.

Yes, that should be cleaned up: ideally rules_verilator would be in bazel bcr and depend on other things in bazel bcr as needed. rules_verilator is a stopgap solution where the hope is to depend on a cleaner future rules_verilator in bazel bcr and retire the stopgap solution.

[MrAMS]

You are right, I see the picture now. I should focus my further work and contributions directly on OpenROAD.

By the way, I just discovered rules_verilator. Would migrating this to the BCR solve the issue?

[oharboe]

You are right, I see the picture now. I should focus my further work and contributions directly on OpenROAD.

By the way, I just discovered rules_verilator. Would migrating this to the BCR solve the issue?

I have not looked at it. What we're using today(myself and OpenROAD) is https://github.com/Pinata-Consulting/rules_verilator. I don't know the exact history but I think it was split of from rules_hdl in anticipation of rules_hdl work being knocked into shape and submitted to bazel bcr as idimoatic individual single concern modules.

Ideally, someone would take all the good work that is done, sort through it and create a rules_verilator in bazel bcr that everybody can migrate to.

[MrAMS]

Hi @oharboe , I have migrated rules_verilator to blzmod, see pr

[MrAMS]

check this Use BCR verilator and localize verilog providers #423, I switch from custom registry Pinata-Consulting/rules_verilator to BCR verilator 5.036.bcr.3. Now we should get rid of rules_hdl?