openroad errors out with pin access check error in IO pad opening

[chaufe]

Describe the bug

I use OpenLane + OpenROAD to create a pad ring using GF180MCU pad cells. When getting into phase "26", the detailed router gets invoked. The detail router errors out with pin access errors on the pad openings of the IO cells (pin PAD), that are also defined as the modules main inputs / outputs.

[ERROR DRT-0073] No access point for pad_din/PAD. [ERROR DRT-0073] No access point for pad_dout/PAD. [ERROR DRT-0073] No access point for pad_clk/PAD. Error: droute.tcl, 38 DRT-0073 child process exited abnormally

A work-around is to mark the nets connected to the PAD pin and module inputs/outputs as "special net".

If these nets are marked "special nets", the detailed router continues without pin access errors.

Please find attached a test case (ipython notebook) that can be executed in Google Colab to reproduce the issue:

OpenRoad__invalid_pin_access_check_on_pads.ipynb.gz

/cc @proppy /cc @dhaentz1

Expected Behavior

The detailed router should know by the pin type and by its connection to the module I/Os, that it should not try to route to the PAD pins, even w/o explicitly marking the nets connecting the PAD pins as "special nets".

OpenROAD Environment

Env.sh seems not to be included in my litex-hub package - please use the testcase notebook to extract data.

OpenLane Environment

env.py seems to be broken in my setup - please use the testcase notebook to extract data.

To Reproduce

_build.zip

Relevant log output

[STEP 26]
[INFO]: Running Detailed Routing (log: runs/RUN_2023.06.29_11.44.31/logs/routing/26-detailed.log)...
[ERROR]: during executing openroad script /content/eda/share/openlane/scripts/openroad/droute.tcl
[ERROR]: Log: runs/RUN_2023.06.29_11.44.31/logs/routing/26-detailed.log
[ERROR]: Last 10 lines:
[INFO DRT-0033] Via3 shape region query size = 2760.
[INFO DRT-0033] Metal4 shape region query size = 25741.
[INFO DRT-0033] Via4 shape region query size = 1506.
[INFO DRT-0033] Metal5 shape region query size = 13841.
[INFO DRT-0165] Start pin access.
[ERROR DRT-0073] No access point for pad_din/PAD.
[ERROR DRT-0073] No access point for pad_dout/PAD.
[ERROR DRT-0073] No access point for pad_clk/PAD.
Error: droute.tcl, 38 DRT-0073
child process exited abnormally

[ERROR]: Creating issue reproducible...

Screenshots

No response

Additional Context

No response

[vijayank88]

@chaufe Attach issue_reproducible generated by the flow. Given attachment is not valid test case.

[maliberty]

What pin type are you seeing on the PAD pin? I'm looking at a proprietary PDK that just uses SIGNAL. If you use ICeWall it should mark these nets as special.

[chaufe]

@vijayank88 I've added a _build.zip containing data created by or_issue.py

@maliberty The pin type is "SIGNAL", the pad is CLASS PAD AREAIO, but using CLASS PAD INPUT and CLASS PAD INOUT would give the same result. The I/O pads have already been instantiated in RTL, and only been placed using place_pad.

[maliberty]

There is no reason for the router to assume it can't route a signal net to pad.

[chaufe]

How would the router know if it should try to route to the pad or not? As a user, I would expected the pad to be only connected by a bond wire, or - if available - by a redistribution layer to a bump. Is there a special requirement OpenROAD has on the pad class or pin type so it would not try to route to the pad?

[rovinski]

In general, unless a net is

1. Already routed
2. Marked as special
3. A supply net (power / ground)

The detail router will try to route it. The RDL router should be run before the detail router to ensure any pad / RDL connections have already been routed. I believe that RDL nets are generally marked as special, anyways.

[chaufe]

@rovinski I agree with your points. But I'm still wondering:

1. Why does the detail router stop when checking pin access? It could as well leave the net unconnected but report it as a routing error / open net.
2. Why does the net connected to the pad opening not get marked as a special net? (i.e. when calling place_pad) Of cause, this can be done by user code, but for most users switching from proprietary tool flows, this is at least a very unexpected task to do.

I also think the issue has been introduced earlier this year. Earlier versions of OpenROAD would not complain about pin access on the pad opening even if the IO pad cells were just placed using the macro config file.

[rovinski]

Why does the detail router stop when checking pin access?

I'm not sure; I believe it's mostly a design decision. The latter parts of the routing algorithm depend on having valid pin access points and so not finding any valid access points will lead to more trouble down the line.

It could as well leave the net unconnected but report it as a routing error / open net.

I think we mostly abide by the philosophy of "fail early". It is a common problem among EDA tools that errors are lost in the noise, and then your job runs for hours or days without any hope that it will complete successfully. OR tries to detect problems early and error if there is no hope of a good solution.

Why does the net connected to the pad opening not get marked as a special net?

I am not well-versed in the OpenLane flow, I mostly work with ORFS. Does OpenLane perform RDL routing for gf180? The PAD tool I believe marks the RDL nets as special nets. Otherwise, the nets have to be marked as special by the user. OR will never try to infer a net as special; it has to be explicit. I believe this is consistent with commercial tools.

[chaufe]

For my case, this is an IO cell with bond pad, so no RDL routing is involved. (An I think there is no RDL in that PDK / metal stack)

I still believe setting this net to special should be done inside place_pad. Knowing the instance to be of CLASS PAD AREA_IO, having one of its pins being a top-level port, and being placed by place_pad (plus maybe a pin size check) should suffice for a good guess to decide if a net needs to be a special net that is not intended to be routed by drt.

In my experience with commercial tools, I never had to mark IO nets special.

[rovinski]

Is the pin directly on the pad and the pad is either contained by the I/O cell or connected by abutment? If so I can see where the problem might come in. The pin access check is done before any abutment checks, so the pin access check doesn't know whether a pin is abutting and it can ignore the pin access check.

In my experience with commercial tools, I never had to mark IO nets special.

In all likelihood the nets did get handled by the detailed router but sometimes the tools are smart enough to recognize abutted pins. I have seen cases in both of the major P&R tools where abutted I/O pins were handled well and not well when forgetting to annotate them as special nets.

[maliberty]

place_bondpad will mark the associated net as special. place_pad does not as it is simply placing the IO. Are you using the former?

[chaufe]

I'm using place_pad, as the bond pad is already part of the I/O cells for gf180mcuC I/Os. There is no extra bond pad master inside gf180mcuC I/O IP.

[maliberty]

@gadfort any thoughts on this case with an integrated bond pad?

[gadfort]

@maliberty probably needs a modification to ICeWall to indicate that the wirebond cells are integrated. I can take a look, but a runnable testcase would be very helpful. Are the ones attached working?

[maliberty]

I haven't tried.