https://open-source-silicon.dev logo
Join Slack
Powered by
Mmm, I'm hitting an issue where the GDS generated ...
# magic
t
Mmm, I'm hitting an issue where the GDS generated by Magic and by klayout are different, and in this case I think klayout is right.
DNP5egt_d.webpTIQOIAq_d.webp
t
NONDEFAULTRULES are a pain and I am not entirely surprised. . . How is 
analog_track
defined?
t
Copy code
NONDEFAULTRULES 1 ;
    - analog_track
      + LAYER li1 WIDTH 900 SPACING 2700
      + LAYER met1 WIDTH 900 SPACING 2700
      + LAYER met2 WIDTH 900 SPACING 2700
      + LAYER met3 WIDTH 900 SPACING 2700
      + LAYER met4 WIDTH 900 SPACING 2700
      + LAYER met5 WIDTH 900 SPACING 2700
    ;
I couldn't find another way thatn using theses to have some wires be wider ...
Something suprising though is that when I'm loading the DEF locally the tracks end up on the right layer 🤔
t
Wait, what?
Okay, can you please carefully go through the sequence of events that gets you the incorrect GDS?
t
Well it's whatever OpenLane2 does 😅 I'll try to read though what it does to see if there is something special it does ...
t
So you're saying the openlane2 generated both the DEF file and the GDS, and the GDS looks like the left side screenshot above. But if you manually read the DEF file generated by openlane2 and generate GDS from it yourself, it looks like the right side screenshot above. Have I got that right?
t
Well OpenLane2 works on DEF for the beginning of the flow, then at some point feeds the DEF/LEF to both magic and klayout to generate GDS from that that and then it compares the output and reports an error if they don't match. Those two GDS are what I posted screenshot from. Then I also independently took the DEF, copied it to my laptop and read it in magic using 
def read
(and nothing else, so I get a bunch of errors about missing macros and such, but I do see the routing data) and there looking at magic UI (I didn't try to do gds write) I see the trace in the right layer.
t
That is. . . bizarre. If openlane were somehow picking up an older version of magic that didn't implement the non-default rules (which would be about two years out of date), then I would expect the correct metal layer but the wrong route width. If the layout shows the right layer, then there is no way that it can write the wrong layer on GDS, so the problem must happen on the DEF read, somehow. I guess you just did 
lef read
and 
def read
with no special options when you did it manually?
t
Ok, so doing just the 
def read
on the magic from OL2 (which runs remotely on a different machine) shows the problem. So either it's linked to that version, or it's a "random" issue and just doesn't appear on my machine.
OL2 version is 
8.3.464
and mine is 
8.3.465
so I doubt it's a version issue.
t
Uh oh. I hate random issues. Probably another uninitialized variable. Can you post the DEF file to me so I can try to reproduce the problem?
t
Sure.
openframe_project_wrapper.def
openframe_project_wrapper.def
One thing is that the issue only appeared after I used the custom via.
So I think this might be more related to the via than the non default rule ... (or the combination of both)
t
I can reproduce the problem on my end. Loading manually. I'm not sure how you managed not to make it happen. . .
t
Just tried to use the normal techn via instead of my custom ones and there the tracks are on the right layer but have the wrong width 😅
Sgj3hCU_d.webp
t
One problem at a time, please. . . : )
👌 1
I think I have pinned down the issue, roughly; I put a breakpoint on the code where it tries to figure out what metal layer it should be on after the route leaves a via, and that code didn't get triggered by any of the non-default routes.
The non-default via somehow got registered with its type set to metal4 instead of via3. Getting closer. . .
🤞 1
Okay, I fixed the first problem and now the 2nd problem has surfaced. Working on that. . .
🙌 1
I just pushed the fixed code to the opencircuitdesign.com repository, magic version 8.3.466.
t
Trying it now ...
@Tim Edwards Indeed, works perfectly now 🎉
Thanks a lot for the very quick fix 😀
t
An error which causes nets to get shorted in a layout is automatically a high-priority item.
✅ 1
t
Oh ... this might have had some un-intended side effects though.
The vias of all the 
pdngen
connections are now different between klayout and magic.
This one might be on klayout though, I need to dig into this more.
Nope definitely a side effect of the change. Before vs after :
uIYMXIs_d.webpjDgtLDB_d.webp
The signal got properly moved to 
met4
but the via on the PDN rails changed. More cuts and the 
met4
rail got widened too. (and those met4/met5 via got changed all over the place, sometime creating DRC violations).
( 
Metal5 overlap of via4 < 0.12um (met5.3 - via4.4)
)
t
Apparently I have never thoroughly tested VIAGEN statements. I think this is just a similar issue as the other one; a failure to check which layer of the generated via is the contact cut. I think what happened is that it replaced the top metal layer area with a drawn contact in magic, and then magic regenerated the cut layers from that contact area instead of the original cut area.
@tnt: Okay, now it should be fixed (actually it was a side effect; my bug fix was not quite right. Now the layout is DRC clean after reading the DEF, and the contact cuts are in the right place).
t
@Tim Edwards 🎉
Yup, I can confirm this works, the full flow completes successfully now.
@donn Whenever you get the chance to pull that into OL2 😅
d
4 Views
Open in Slack
PreviousNext
Powered by