Basically for some pins the name of the pin end up...
# magic
t
Basically for some pins the name of the pin end up ... wrong, it uses the name of an inside net inside.
Theses are the GDS and LEF ( viewed in klayout ) written by magic.
pad_uio_oe_n_buf_I[2].z
should be
pad_uio_oe_n[2]
Copy code
- pad_uio_oe_n[1] + NET pad_uio_oe_n_buf_I\[1\].z + DIRECTION OUTPUT + USE SIGNAL
      + PORT
        + LAYER met4 ( -150 -500 ) ( 150 500 )
        + PLACED ( 28980 219820 ) N ;
    - pad_uio_oe_n[2] + NET pad_uio_oe_n_buf_I\[2\].z + DIRECTION OUTPUT + USE SIGNAL
      + PORT
        + LAYER met4 ( -150 -500 ) ( 150 500 )
        + PLACED ( 23460 219820 ) N ;
    - pad_uio_oe_n[3] + NET pad_uio_oe_n_buf_I\[3\].z + DIRECTION OUTPUT + USE SIGNAL
      + PORT
        + LAYER met4 ( -150 -500 ) ( 150 500 )
        + PLACED ( 17940 219820 ) N ;
The above is the
PINS
section of the DEF and you can see how it's written (and it's the same for all the
pad_uio_oe_n
signals but only that one has the issue.
As you can see in the
GDS
view, there are two labels that end up on the pin area due to the geometry I guess ... ?
t
@tnt: I'm pretty sure this is the same error I was looking at recently, so it's on my radar. I recently changed a setting to allow all labels in a design to be output to the .ext file; if they belong to the same net, they are put in an "equiv" statement. Somewhere in the processing, a port can lose port status, and then it can get exchanged for any other label on that net. I have not yet figured out how the port status flag is getting cleared.
There is an "extract" option that disables the "equiv" statements---you might try "extract no aliases" as a workaround.
t
👍 I'll give that a shot thanks !