Please help debug pin access

[growly]

Describe the bug

During detailed routing, pins on my custom cell cannot be accessed and I'm unsure why. For example, I get errors like this:

[WARNING DRT-6000] Macro pin has more than 1 polygon
[WARNING DRT-6000] Macro pin has more than 1 polygon
[WARNING DRT-6000] Macro pin has more than 1 polygon
[WARNING DRT-6000] Macro pin has more than 1 polygon
[WARNING DRT-6000] Macro pin has more than 1 polygon
[WARNING DRT-6000] Macro pin has more than 1 polygon
[WARNING DRT-6000] Macro pin has more than 1 polygon
[ERROR DRT-0073] No access point for bfg_mux/i1.

The cell has many pins, shown in this lef (also attached): gf180_mux.lef.zip

Some of them are clearly trickier than others to get to, but some of them (including i1, i3) seem pretty simple. I get an error for i1 but z seems to work:

Expected Behavior

I'd like to understand how the router negotiates access so that I can design the cell to be accessible by it.

OpenROAD Environment

Not sure which one is being used if I'm honest, I can find out if this is important.

OpenLane Environment

$ python3 ./env.py issue-survey
Kernel: Linux v5.10.0-8-amd64
Distribution: debian
Python: v3.9.12 (OK)
Container Engine: docker v20.10.21 (OK)
OpenLane Git Version: 235fa7a4a2872e779588919c58fc4fa32568e075
pip: INSTALLED
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

235fa7a 2022-11-28T17:17:32+02:00 [BOT] Update PDK (#1516) - Openlane Bot -  (grafted, HEAD, tag: 2022.11.29)
---
Git Remotes

origin  https://github.com/The-OpenROAD-Project/OpenLane (fetch)
origin  https://github.com/The-OpenROAD-Project/OpenLane (push)

To Reproduce

I invoke this through the caravel_user_project Make scripts. It seems to just be running OpenLane. The initial and final config.tcl are attached. config.tcl.zip

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[growly]

Questions about how the router founds legal routes:

• Is it a problem if a pin polygon is touching an obstruction polygon on the same layer?
• Is the router checking for DRC correctness (or constructing routes for DRC correctness) based on only the routes it creates or, for instance, will unrelated DRC errors in the cell cause it to fail?

[growly]

I have made the access pins comically large and comically far apart but I still get pin access errors. Currently, i1_r (input 1 on the right):

[INFO DRT-0033] Metal5 shape region query size = 0.
[INFO DRT-0165] Start pin access.
[ERROR DRT-0073] No access point for bfg_mux/i1_r.
Error: droute.tcl, 38 DRT-0073

LEF: gf180_mux.lef.zip

The cell is DRC clean according to the magic, but the LEF is a bit of a hack job so might be the problem?

[growly]

Leaving the right-side disconnected, the router succeeds in connecting to the other nets but with violations. I'm not sure what's different about the right-hand side?

Here are the routes (with 1 violation allegedly) in the openroad gui:

[maliberty]

It would be helpful to package this as a standalone test case.

[maliberty]

pa access issues can depend on the relative placement of the instance to the routing pattern

[maliberty]

from OL https://github.com/The-OpenROAD-Project/OpenLane/blob/master/docs/source/for_developers/using_or_issue.md

[growly]

Thanks -

When attempting to connect only the right-hand pins the pin access failures occur and the flow automatically creates this issue_reproducible package: bfg_mux_test_right_pins_access_failure.tar.gz

When attempting to connect only the left-hand pins, pin access seems to have been figured out but there is a violation and the flow ends prematurely. I have attempted to package the artefacts manually, but I'm not sure I got the right script or right input DEF: bfg_mux_test_left_pins_routed_but_violating.tar.gz

[maliberty]

The left pins test is off:

set ::env(CURRENT_ODB) {./tmp/routing/16-global.def};

a .def is not a .odb.

[maliberty]

There is no lef included so I can't even piece it together.

[maliberty]

Your cell gf180mcu_mux has bad shapes in its i1_r pin:

MANUFACTURINGGRID 0.005 ;
MACRO gf180mcu_mux
    PIN i1_r
        PORT
            LAYER Metal1 ;
              RECT  11.455 1.975 11.795 2.17 ;
              RECT  11.455 2.17 11.795 2.899 ;
              RECT  11.455 2.899 11.795 4.584 ;
              RECT  15.69 4.529 16.08 4.584 ;
              RECT  11.455 4.584 16.08 4.814 ;
              RECT  15.69 4.814 16.08 4.869 ;

your shapes are off the manufacturing grid. All the above coordinates need to be a multiple of 0.005. All attempts at pin access always yield an off-grid violation because the cell itself is bad.

[growly]

Ah, thank you! So by fluke it seems the working pins are all on the grid. So then this isn't DRC clean, possibly because the magic checks don't include it and I needed to run the klayout DRC checks too.

PS.

1. The example in the instructions specifies a DEF, not an ODB, so that's what I gave it. Here is the repackage: bfg_mux_test_left_pins_routed_but_violating.tar.gz

2. LEF was attached to a previous comment ( gf180_mux.lef.zip) but I think you've got a post-rectangle-covering version anyway

[maliberty]

Likely or_issue directions were not update for the switch from def to odb. You could file an OL doc bug.

[maliberty]

I would expect magic to check off grid

[growly]

I had expected that too. Probably my error, I'll look.

[growly]

I can confirm that with all units snapped to a 0.005 um grid routing completes successfully:

I can also confirm that magic does not catch this error!