Segfault in one of OpenLane's steps (or_replace.tcl) #754
Comments
|
@progirep mpw-3b is right version for caravel project. Try with mpw-3b tag |
Thanks, I will try that and report back in ~2-8 hours. |
donn
added
bug
Don't worry, this isn't Tcl. We don't require any Tcl knowledge beyond |
|
@donn this issue reproduced with mpw-3b tag as well |
|
@vijayank88 Really not much I can do other than or_issue the reproducible and try it with the latest version of OpenROAD. However, I'm off this week, so that'll have to wait until Monday. |
|
Ok, I've just checked with the "mpw-3b" version of the OpenLANE docker container. The segfault occurs as well, and the stack trace is the same up to the memory addresses (which are unlikely to be the same because of address space randomization). The problem does not occur for the design from which my test design is forked. I'll have a look if there is something to be seen from the differences between the OpenLane warnings - in case the segfault only occurs for designs that have no chance to work anyway, there may be some useful information hidden to track down the problem. |
|
@progirep This failure occurs inside the OpenROAD app specifically, so there's not much we can do on our side but package the issue and pass it on to the OpenROAD team. Likely there's a corner case exposed by your design that's just not handled properly. |
|
It is helpful if it can be packaged with scripts/or_issue.py |
|
@progirep |
|
@progirep segfault error comes from openlane/Makefile. |
vijayank88
added
waiting on op
|
Ok, so I've attached the tar file for reproducing the issue built according to the using_or_issue.md document: The proposal to change the Makefile didn't work for me. It had no effect on the error. If I get it correctly, the change is for "injecting" the local OpenLane checkout from OPENLANE_ROOT into the docker container. I was using the "mpw-3a" version for that previously (which seems to be the one coming from this pull request: #675). Updating to a newer version of it leads to the whole build process failing with "[ERROR STA-0402] repair_design -slew_margin is not a known keyword or flag." - appears to be some version mismatch. I guess that the slack link was posted for internal use because signing up requires e-mail addresses from few domains (google but not gmail, efabless, ..) |
|
Your packaged testcase suggests you are using an old version of openlane. What commit are you on? |
donn
removed
the
waiting on op
|
I can't reproduce the issue with a later version of OpenROAD. Meaning that this issue is waiting on #756. |
donn
added
blocked
|
Thanks for testing it with a later version of OpenROAD. I apologize for having to take back my statement that the problem occurs with the "mpw-3b" version of efabless/openlane for me as well. I only noticed today that the file "openlane/Makefile" from https://github.com/efabless/caravel-lite has the "mpw-3a" version of Openlane hardcoded, and hence the selected openlane tag in the project's own Makefile (which I got from https://github.com/VLSIDA/openram_testchip/blob/main/Makefile) does not have any effect. When changing the caraval-lite makefile to refer to the "mpw-3b" version of efabless/openlane, the segfault indeed vanishes (with or without changing "/openLANE_flow" to "/openlane" in "openlane/Makefile" of the project). Now I'm getting "[ERROR GRT-0229] Vertical edge usage exceeds the maximum allowed." as error message, including when using the latest master branch of openroad. But that reads like a problem with the design. So thanks! |
|
No problem! Just happy we could help. |
Description
I'm getting a segfault in one of OpenLane's steps, but can't see what a possible reason for this could be (sorry, I don't "speak" TCL nor do I use docker for my own work - I'm only doing a few assembler styles, C, C++, Python, Java, some HDL, and CS Theory).
The project on which the problem occurs is a test project for integrating OpenRAM blocks into a design - it is a shortened version of the project at https://github.com/VLSIDA/openram_testchip.git using only two SRAM blocks.
Environment
The problem occurs both with the mpw-3a version of the workflow as well as with the "latest" (b911a5bbbcaa) version of the OpenLane docker images (selected by changing the respective lines in the files "Makefile" and "openlane/Makefile"). In the case of the "latest" version latter case, the gds.gz files in the gds/ directory of the project need to be gunzipped for the flow to reach the segfault. Also, when using the "latest" version, there is a warning for me that the PDK version is then not the right one - not sure if this is relevant because the segfault is the same.
Reproduction Material
Github doesn't let me upload the project as a tar.gz file or a .zip file with the message "is not included in the list". Maybe it is too large. So I've committed the project as a project to github at: https://github.com/progirep/openram_testchip/tree/8ae25c1d4a85146cf2a7d277da1f87e1234a4b85
The following zip file is just a dummy to be able to submit the issue anyway:
The command to run is simply:
from the project directory.
Expected behavior
The workflow should not segfault. The project I'm trying to run it on may be wrong in some aspects, but right now it's not possible for me to tell because of the segfault.
Logs
The text was updated successfully, but these errors were encountered: