The-OpenROAD-Project
synth: Add yosys-slang option; demonstrate on Ibex
Leaving a note to update the bazel file for Ibex, I'm guessing it will now be
filegroup(
name = "verilog",
srcs = glob(include = ["*.v", "*.sv"]),
visibility = ["//visibility:public"],
)
which will pick up both .v and .sv files, inclusive of subdirectories (until now it only had to pick up .v)
@maliberty @povik Has it been decided to ship the slang binary in the ORFS docker image?
If ORFS is to contain a test-case for slang and to offer a way to test slang, then I'm thinking that ./build_openroad.sh would need to support building slang for docker and local.
If ORFS is to contain a test-case for slang and to offer a way to test slang, then I'm thinking that ./build_openroad.sh would need to support building slang for docker and local.
Yes, if we go ahead with this we need to add yosys-slang to build_openroad.sh, the documentation, and other places.
I was thinking it would be a dependency installer addition. Do you think we need to put it in the ORFS build?
I was thinking it would be a dependency installer addition. Do you think we need to put it in the ORFS build?
Will it get into the official ORFS docker image?
I was thinking it would be a dependency installer addition. Do you think we need to put it in the ORFS build?
I haven't realized it until now but we need to because it depends on Yosys, and Yosys is built as part of ORFS
Is slang separate from yosys-slang? Wondering if slang would be a dependency.
Yosys-slang compiles against a specific slang vesion and sometimes I have to do patches. It's a pinned submodule somewhat like openroad and opensta
To get a sense of the compilation runtime I compared it against Yosys just now:
Yosys
real 3m13.631s
user 21m27.703s
sys 0m45.744s
yosys-slang (inclusive of slang)
real 1m22.555s
user 6m57.400s
sys 0m20.017s
@povik , how do I pass additional options to yosys-slang? When I ran it standalone, I included -Wno-index-oob --ignore-assertions to get mempool_group to go through.
@jeffng-or I want to see if we can set it up so that per-design options are almost never required. For mempool_group --compat=vcs should take care of the index-oob error and I've now added --ignore-assertions.
should build scripts be updated first to produce slang in the ORFS docker image?
I think yes. That's why this is a draft.
@jeffng-or Please pull again and try on mempool_group. The issues you saw were due to: not specifying the top (so it tried elaborating some unrelated modules) and not sequencing the read-in of Liberty files before slang
To clarify those were issues with the synthesis script, not with the design configuration
To clarify those were issues with the synthesis script, not with the design configuration
When running with --top after pulling, I get a seg fault. I also saw this when creating the mempool_group.tcl standalone script:
3. Executing SLANG frontend.
munmap_chunk(): invalid pointer
Aborted (core dumped)
food for thought...
why make slang a submodule? why not just compile it in the installer scripts? same could be said for yosys. ORFS uses yosys, slang, klayout, tcl, qt, etc. unchanged....
openroad is much more tightly bound to ORFS, but even openroad doesnt really have to be a submodule.
why make slang a submodule? why not just compile it in the installer scripts? same could be said for yosys. ORFS uses yosys, slang, klayout, tcl, qt, etc. unchanged....
The version of both yosys-slang and Yosys can influence the synthesis result so it needs to be pinned for metric reproducibility. I guess we could specify the revision of those in build_openroad.sh instead of a submodule but what's the advantage?
why make slang a submodule? why not just compile it in the installer scripts? same could be said for yosys. ORFS uses yosys, slang, klayout, tcl, qt, etc. unchanged....
The version of both yosys-slang and Yosys can influence the synthesis result so it needs to be pinned for metric reproducibility. I guess we could specify the revision of those in build_openroad.sh instead of a submodule but what's the advantage?
My thinking is a submodule is an anachronism mostly and in any case more a match for development than dependency management. For dev monorepo/git subtree is more modern.
My thinking is colored by the conclusions of engineering lessons learned and applied in e.g. Bazel. Bazel handles this with pointers to reps and patches and is much more flexible. faster.
With a submodule it is not immediately obvious where it comes from(where is the link to the original rep documented?) and if/how the dependency was tweaked.
For now, the equivalent in ORFS is build_openroad.sh as you point out
on the subject of git subtree/monorepo and submodules, I like the idiomatic feature of making it trivial for developers to simply work in orfs, not worrying at all about the distinction between orfs and openroad. This allows doing stuff such as creating a PR that modified OpenSTA, OpenROAD and updates ORFS tests in a single PR trivially.
Not suggesting to switch what is in submodules today, but I would not encourage using submodules going forward....
A submodule is nothing more than a link to a commit in another repo. See https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/tools
The slang plugin has successfully built within CI, and nangate45/ibex passed the metrics:
16:13:49 [INFO] synth__design__instance__area__stdcell pass test: 28749.812 <= 32828.58
16:13:49 [INFO] constraints__clocks__count pass test: 1.0 == 1.0
16:13:49 [INFO] placeopt__design__instance__area pass test: 33715.8 <= 36863.0
16:13:49 [INFO] placeopt__design__instance__count__stdcell pass test: 16839.0 <= 18834.0
16:13:49 [INFO] detailedplace__design__violations pass test: 0.0 == 0.0
16:13:49 [INFO] cts__design__instance__count__setup_buffer pass test: 84.0 <= 1638.0
16:13:49 [INFO] cts__design__instance__count__hold_buffer pass test: 1.0 <= 1638.0
16:13:49 [INFO] globalroute__antenna_diodes_count pass test: 0.0 <= 0.0
16:13:49 [INFO] detailedroute__route__wirelength pass test: 341639.0 <= 363762.0
16:13:49 [INFO] detailedroute__route__drc_errors pass test: 0.0 <= 0.0
16:13:49 [INFO] detailedroute__antenna__violating__nets pass test: 0.0 <= 0.0
16:13:49 [INFO] detailedroute__antenna_diodes_count pass test: 0.0 <= 5.0
16:13:49 [INFO] finish__timing__setup__ws pass test: -0.23893 >= -0.29
16:13:49 [INFO] finish__design__instance__area pass test: 34964.9 <= 39536.0
16:13:49 [INFO] finish__timing__drv__setup_violation_count pass test: 418.0 <= 832.0
16:13:49 [INFO] finish__timing__drv__hold_violation_count pass test: 0.0 <= 291.0
16:13:49 [INFO] finish__timing__wns_percent_delay pass test: -8.910522 >= -21.31
A submodule is nothing more than a link to a commit in another repo. See https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/tools
I am aware. And that is all that it is. Same goes for a dependency in build_openroad.sh and the installer.
gitsubtree/mpnorepo is different.
A practical difference between submodule and build_openroad.sh/Bazel MODULE.bazel is that the files are visible to everyone who works on ORFS with a submodule.
Modern editors run discovery and are excited to find e.g. cmake files git submodules and bring up needy dialogs....
This over time becomes a disaster of the commons: the disadvantage of this is shared by everyone working on ORFS and the advantage of having slang files is enjoyed only by those that work on slang.
If you are aware then why ask "where is the link to the original rep documented?"
If you are aware then why ask "where is the link to the original rep documented?"
For ORFS, it points to a fork for OpenROAD. So sometimes the information can be missing.