@Tim Edwards I have a weird behaviour of the lef generation of magic, it generates an obstruction but the obstruction is too small, and so the pdn generated by openlane bleeds into the macro. As a workaround I manually changed the obs in the lef file, but I am wondering why it fails. This is the script: https://github.com/thesourcerer8/gf180teststructure/blob/tapeout/gf180_teststructures/lef.tcl

What is your intent with the script? Your layout starts at Y=305um, and then you are adding some ports down at Y=0. The

lef -hide

should only draw obstruction layers to the extents where it sees geometry. That said, I have no idea why the ports you created down at Y=0 are not causing the metal 4 obstruction to stretch down to where the pins are. That would be my expectation of the behavior. Is that what you're referring to?

I don't think the the ports are creating a problem and are relevant. It loads the gf180_teststructures.gds on the top, and then it writes the LEF file out at the bottom, and that obs in the LEF is too small:

Are you getting this LEF file? Because it has obstructions where I would expect them to be, at the extent of the layer geometry.

Now I just noticed the following output, could this be the problem? CIF file read warning: Input off lambda grid by 4/5; grid redefined. CIF file read warning: CIF style import: units rescaled by factor of 5 / 1

It's not clear to to me from the screenshot that Openlane has caused any violations in the power routing. The vertical stripes are metal4 and pass underneath the pads on the right and left. If you don't want the power routes extending over your test structures, you might want to drop a horizontal wire of metal4 extending the width of the design, one at the top, above all your test structures, and one at the bottom, below all your test structures.