https://open-source-silicon.dev
Join Slack
I'm having some trouble when generating a LEF with -pinonly. The geometry in the pin in incorrect, i...
# magic
t
I'm having some trouble when generating a LEF with -pinonly. The geometry in the pin in incorrect, it includes metals from other pins ... Using https://github.com/iic-jku/sky130_power_gate/blob/main/tt_pg_vdd_2/tt_pg_vdd_2.mag I do :
Copy code
load tt_pg_vdd_2
lef write tt_pg_vdd_2_ko.lef -hide -pinonly
lef write tt_pg_vdd_2_ok.lef -hide
lef write tt_pg_vdd_2_ok2.lef -hide -pinonly
First off if you look at 
ko
and 
ok2
although they are generated with the same command, they end up being different. ( Bug only happens when it's the first thing you run ). Then if you look at the diff :
Copy code
PIN VGND
     DIRECTION INPUT ;
     USE GROUND ;
     PORT
       LAYER met4 ;
         RECT 0.000 0.000 1.200 224.240 ;
     END
     PORT
       LAYER met4 ;
+        RECT 0.000 0.000 1.200 224.240 ;
         RECT 8.000 0.000 9.200 224.240 ;
     END
   END VGND
   PIN VPWR
     DIRECTION INPUT ;
     USE POWER ;
     PORT
       LAYER met4 ;
+        RECT 0.000 0.000 1.200 224.240 ;
         RECT 1.700 0.000 4.350 224.240 ;
+        RECT 8.000 0.000 9.200 224.240 ;
     END
   END VPWR
You can see that the geometry from 
VGND
is also now present in 
VPWR
for some reason ...
t
I am unable to duplicate this. What version of magic are you using? But, oddly, I'm also seeing that I get the same output for all three cases---like "-pinonly" is assumed when I run "-hide". Since the lower metal layers are connected to the pins, they should have been marked as pins, not obstructions. . .
t
I'm running 
8.3.463
Starting with 
magic -rcfile /mnt/pdk/OL2/pdk_root/sky130A/libs.tech/magic/sky130A.magicrc -d cairo
and then immediately cut & pasting the commands above without doing anything else in between.
t
What OS are you doing this on? Can you please tarball and post all three LEF files? There is something OS-dependent going on, which sometimes means an uninitialized variable in the code.
The fact that it behaves differently on different passes is also consistent with an uninitialized variable.
t
This was a self-built magic on Linux amd64 (debian bullseye). It also happen on the 
8.3.452
shipped with OpenLane2 when running in nix.
tst_magic.tar.bz2
tst_magic.tar.bz2
t
@tnt: I did find an uninitialized variable issue (actually just looking at the wrong record of a structure) in the LEF writing code that is the only thing I could find that might be relevant. I fixed that and updated the magic version number to 8.3.464 (this is on the opencircuitdesign.com repo, not mirrored to github). Can you please grab that version and tell me if it solves the problem or not?
t
@Tim Edwards Unfortunately that didn't solve the issue.
t
Okay, I have a laptop with PureOS Byzantium, but it's basically the equivalent of Debian bullseye, and I can confirm the problem on that. So it should be easy enough to track down where my two versions diverge.
👍 1
@tnt: Okay, I just pushed another fix that I'm certain fixes the problem this time. It does not involve an uninitialized variable, but it does involve "lef write" using the selection mechanism without initializing it correctly, so that the first net selection doesn't get cleared properly and is still in the selection buffer when the 2nd net is selected. I could reproduce the problem on any machine. At first I didn't think it was failing on my Fedora machine because I didn't understand that it only happens on the first run of "lef write", so I was doing it over and over and not seeing any error.
t
@Tim Edwards Yup, I can confirm this fixes it, thanks !
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by