Basically for some pins the name of the pin end up ... wrong, it uses the name of an inside net inside.
tnt
06/02/2023, 1:44 PM
Theses are the GDS and LEF ( viewed in klayout ) written by magic.
tnt
06/02/2023, 1:45 PM
pad_uio_oe_n_buf_I[2].z
should be
pad_uio_oe_n[2]
tnt
06/02/2023, 1:45 PM
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 ;
tnt
06/02/2023, 1:46 PM
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.
tnt
06/02/2023, 1:47 PM
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
Tim Edwards
06/03/2023, 8:43 AM
@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.
Tim Edwards
06/03/2023, 8:44 AM
There is an "extract" option that disables the "equiv" statements---you might try "extract no aliases" as a workaround.
Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.