Closed lustefan97 closed 11 months ago
@lustefan97 I've run this test case with the latest OpenROAD and the error is not happening anymore. We had a few fixes in GRT since the PR you mentioned, so it's possible that this issue was already fixed.
I just updated OpenROAD-flow-scripts using build_openroad.sh --latest
, when using etc/Env.sh it reports "Git commit: ed356f36fab23fcbf857925a0c04178d431b203f" which is the commit from the master branch yet I still have that exact same issue...
Although I do admit, this message did not seem to appear on another design (the same basically, but multiple one in a bigger top-level module), for reasons that I don't understand...
@lustefan97 I did not have the error, but I see a weird behavior that is probably the cause for this error. The global router creates the guides correctly, with guides covering the pins placed at the top level, but the detailed router seems to modify the guides, removing this top layer guide. I'll investigate why this is happening.
@lustefan97 I did not have the error, but I see a weird behavior that is probably the cause for this error. The global router creates the guides correctly, with guides covering the pins placed at the top level, but the detailed router seems to modify the guides, removing this top layer guide. I'll investigate why this is happening.
After debugging a little bit more, I noticed that it was not an issue. After creating the stack of vias to connect to the top layer pin, the detailed router will remove the top layer guides since it won't be needed anymore to proceed with the routing. I've tested it in CentOS and MacOS, and I don't have an error in any of them.
@lustefan97 Could you try running the attached files on the same machine you're having the issue with? Just unzip it and run openroad run.tcl
. It should be using the same routing config from your run.
@eder-matheus The files you gave me did work indeed, it is now going into the detailed routing optimization steps.
I don't really understand what is happening right now, if it was the OS I use an ubuntu 22.04 docker, which has never really gave me any trouble except for now...
I don't really understand what is happening right now, if it was the OS I use an ubuntu 22.04 docker, which has never really gave me any trouble except for now...
Yeah, it seems really weird. Could you confirm the OpenROAD version when you run the binary? It should be in the beginning of the log. Perhaps you're compiling the correct version, but using another binary?
Also, the zip file you've sent me is the correct one? Maybe you attached the wrong file. I didn't see any reference to SYNTHESIS_HIERARCHICAL in the files you sent me.
The version of OpenROAD reported when running the binary is OpenROAD v2.0-11343-ged356f36f (if this is what you meant, it is the very first thing that is reported when calling OpenROAD.
Regarding SYNTHESIS_HIERARCHICAL, to synthesize my modules I use the Yosys script used in the automatic flow (as I haven't managed to properly make a custom one, and I didn't want to waste more time than necessary on this step). Usually the test case that I send a related to OpenROAD and OpenROAD only, the .v file is the post synthesis RTL file (1_synth.v) from the automatic flow. What I do is that I synthesize the designs using the automatic scripts from ORFS, then move the result RTL into a custom director in OpenROAD/test/ to use it in a custom TCL script.
@lustefan97 Got it. The commit looks correct, so I wonder why you have this DRT issue. The guides look fine, and DRT is appropriately processing them. My only guess is that I'm running a different version of your running, but I wonder if this is the case.
@eder-matheus I think I figured it out.
It was a mistake on my part when uploading the test case. On my end I had modified the asap7_bottom.vars file to not perform any padding during GPL/DPL as it limits the maximum design utilization achievable by OpenROAD (as it stops everything when GPL detect a DU >100%). The "padding variables" were set at zero in my case where DRT fails, while it was still the "default" (global placement padding at 2 and detailed padding at 1) in the test case I sent you...
I attached a new TestCase file that should reproduce the issue, very sorry....
@eder-matheus I think I figured it out.
It was a mistake on my part when uploading the test case. On my end I had modified the asap7_bottom.vars file to not perform any padding during GPL/DPL as it limits the maximum design utilization achievable by OpenROAD (as it stops everything when GPL detect a DU >100%). The "padding variables" were set at zero in my case where DRT fails, while it was still the "default" (global placement padding at 2 and detailed padding at 1) in the test case I sent you...
I attached a new TestCase file that should reproduce the issue, very sorry....
No problem! Thanks for the updated test case. I'll look at it soon.
No problem! Thanks for the updated test case. I'll look at it soon.
Thank you ! I do have a few questions about those guides that I hope you can answer : What are they ? What do they do ? Why do we need them ? What are the difference in use between GRT and DRT regarding the guide ?
I'm curious to know
Routing is hard problem so we divide it into two phases. The global router works on a coarse grid and ignores detailed DRC rules to give an overall solution that should be routable without congestion problems. It passes that solution to the detailed router in terms of a guide for each net. The guide give a set of layers/rectangles that tell the detailed router generally where to put the wires.
The detailed router tries to follow the guides while also dealing with all the detailed drc rules involved in making legal layout.
You can see the guides for a net in the GUI, after global routing, if you select a net and click 'Route Guides':
Oooh yes I remember now, thanks for the answer @maliberty !
@eder-matheus Did you has the possibility to check the test case ? I am currently working on a project and having the flow working in this case would allow me to quickly perform more advanced tests, I am running a bit out of time and having it working would be amazing...
A fix for it should come later today or at most, tomorrow. I'll let you know when the PR is created.
@eder-matheus Sorry to insist... but has a PR been created for this issue ? I don't see anything explicitly related to it in the PR tab...
No, it wasn't. The problem with this case is harder than we first thought, and now @arthurjolo is working to solve it.
Ah I see, thank you !
@lustefan97 Could you try latest master branch? We've merged the fix for this issue.
Describe the bug
Hello,
I have a design which has a known quantity of cells and that I want to use to build bigger and bigger "dummy" designs to perform some tests. To avoid a (rightful) optimization during synthesis I've set
SYNTHESIS_HIERARCHICAL = 1
to allow having multiple time the same design in a top-level module. The problem I have at hand is that, during PnR with OpenROAD and a pin access check, I have a pin that is said "not visited" and then a "Guide not connected to design" error is raised, stopping the flow....Expected Behavior
Hierarchical design routed without issue
Environment
To Reproduce
TestCase.zip
Here is a test case, uncompress the file into OpenROAD-flow-scripts/tools/OpenROAD/test/, enter the TestCase directory and use
bash run_adder_cst_pd.sh
to reproduce the issueRelevant log output
Screenshots
No response
Additional Context
No response