pins are mis-modelled in LEF

[maliberty]

Expected Behavior

The pins is LEF are misusing the PORT statement. To pick a specific example (there are many others) look at MACRO sky130_fd_sc_hddfbbn_1 PIN SET_B [here](https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/ac7fb61f06e6470b94e8afdf7c25268f62fbd7b1/cells/dfbbn/sky130_fd_sc_hddfbbn_1.lef#L68)

In the LEF is has three PORTS in the PIN. According to the LEF manual this implies the pins are weakly connected:

Weakly connected shapes (that is, separate PORTs of the same PIN) are assumed to be connected through resistive paths inside the MACRO that should not be used by routers. The signal router should connect to one or the other PORT, but not both.

These shapes are not weakly connected, they are strongly connected as seen in the GDS. The shapes are on li1 and met1 which are both metal layers and are connected through mcon cuts. They should therefore be in a single PORT.

The impact is to unnecessarily confuse routers about the real connectivity.

Actual Behavior

Three PORTS instead of one.

Steps to Reproduce the Problem

1. Look at the link above.

Specifications

• Version: master branch
• Platform: any

[maliberty]

A side observation is that on met1 you have 5 RECT where three would suffice. It looks like you used a horizontal decomposition rather than a vertical one. Generally the decomp in the non-pref dir will be smaller.

[RTimothyEdwards]

@maliberty :

(1) These entries either come from an older version of magic or from the original vendor LEF. Either way, I confirmed that if I read in the cell from GDS and write out LEF with magic, it will not split the ports up like that. So I can rewrite the makefile for open_pdks so that it generates all standard cell LEF from GDS instead of relying on the LEF in the skywater-pdk repository.

(2) Magic uses a "maximum horizontal stripes" method for plane tiling in its database format. For a while I considered swapping maximum horizontal and maximum vertical stripes methods on route planes depending on the preferred direction, but that was unworkable. There is a routine to copy contents of a plane from maximum horizontal to maximum vertical stripes, so I could use that to orient the LEF port output better.

BTW, qrouter is smart enough to figure out what are the maximum fitting rectangles within a port definition in either direction. Why isn't OpenROAD?

[Stephanommg]

@RTimothyEdwards it is not true that the router of OpenROAD can't figure out maximum rectangles.

[RTimothyEdwards]

Good. In that case I will bump trying to minimize the number of rectangles in the port decomposition to a low priority.

[RTimothyEdwards]

@maliberty : I traced the incorrect PORT use back to the original LEF files from SkyWater. I am testing a solution now in open_pdks in which I am using the SkyWater LEF views to annotate the port use/shape/class but generating LEF directly from magic, which should generate valid LEF macros.

[maliberty]

@RTimothyEdwards thanks! Let me know when you have updates and I'll update ORFS as well.

[maliberty]

@RTimothyEdwards my comments about fracture direction were mostly to point out that the LEF could be minimized. The router has to handle the pin shapes no matter how formed.

[RTimothyEdwards]

@maliberty : Yeah, that's my fault for interpreting it as meaning it was something you needed done. It occurred to me later that if that were true, you wouldn't be able to route any of the SkyWater cells. . .

[RTimothyEdwards]

@maliberty : I just pushed an update to open_pdks that should resolve the issue with multiple PORT entries per pin in the standard cells (open_pdks version 1.0.238).