Closed thesourcerer8 closed 1 year ago
RTimothyEdwards
commented
1 year ago I'm a bit confused by the header "Running Magic Spice Export from LEF" at the top of the output log. LEF is abstract and you can't extract anything from it. But ignoring that, there's the more basic problem that something went wrong with the post and the "issue_reproducible.zip" file above just leads to an empty page with the words "Not found". Feel free to post it to me on Slack if you can't get it to post here.
thesourcerer8
commented
1 year ago RTimothyEdwards
commented
1 year ago 
I'm seeing this weird effect when I read the user_proj_example.gds file where your custom standard cells are drawn at a scale different from everything else. Apparently exactly 10X the intended size. The scale change happened in magic prior to writing GDS, because magic has drawn multiple contact cuts into the contact areas, not one giant 10x size contact cut.
RTimothyEdwards
commented
1 year ago The reproducible zip file has only the files as they are in the middle of synthesis, so I can only see the resulting GDS but not the original files, which makes it impossible to figure out where the scale problem came from. I can investigate the crash condition, which undoubtedly comes from magic trying to deal with the mess in the screenshot above, but ultimately that won't get to the root of this problem.
thesourcerer8
commented
1 year ago The repository with the original files is available at https://github.com/thesourcerer8/gf180_stdcelllib_1 , a "make user_proj_example" should do it. Thanks a lot for that image, I didn't noticed that we have GDS2 already available, I thought it was stuck in the flow before. Ok, so I will care about the 10x scaling and a better placement in parallel.
thesourcerer8
commented
1 year ago Ok, I fixed the 10x scaling, and that seems to have solved the placement problems too, but magic still crashes: issue_reproducible.zip
RTimothyEdwards
commented
1 year ago There are still issues in the layout. If you look at the screenshot above, the pins at the bottom are all arranged such that they abut each other and create a short across the entire row of pins.
Also, each power and ground line of your standard cells has a metal2 line on top of it. This (1) does not match the surrounding cells, which have metal1 only, (2) The metal 2 does not contact metal 1, so is an isolated and unconnected net, and (3) The metal 2 lines are getting routed over by the standard cell router, creating shorts, and suggesting that your standard cells are not representing the metal 2 in the LEF views.
RTimothyEdwards
commented
1 year ago Meanwhile I can duplicate the crash condition, but it's not obvious and may take some time to debug.
RTimothyEdwards
commented
1 year ago @thesourcerer8 : The crash was caused by the excessive number of shorted ports. Since it was not anticipated that anyone would short together several hundred ports, the reference count for shorted ports was set to 1 byte, which you overran. I have fixed the crash condition by extending this to two bytes, on the assumption that shorting together 65,536 ports would require a remarkably concerted effort. Meanwhile, though, your circuit is not going to work until you do something about those pins and all the other shorts in the design.
thesourcerer8
commented
1 year ago Thanks a lot. I didn't experienced that crash anymore, so I think we can close this issue.
Description
*** Error in `/build/lib/magic/tcl/magicdnull': double free or corruption (fasttop):
Expected Behavior
magic should not crash
Environment report
Reproduction material
issue_reproducible.zip
Relevant log output