PlatformBringUp: Pin-access minCut violation

[Damonan]

Hello,

I'm working on locally integrating TSMC 65nm PDK into my ORFS flow. I've encountered an issue with the "pin_access" command for std cells that have large pins. Specifically, I found that the output pin on larger buffer cells is sufficiently large to require 2 vias on the pin to satisfy minCut DRC. I've run "detailed_route_debug -pa -pa_markers -pin <my_cell>:<my_pin>" and stepped through to see visually that the tool tries and fails to place a single via at all possible access points.

Here's my question/concern: It appears to me that the pin_access tool simply is not built to place multiple vias on a pin. Anyone more experienced with this or with TritonRoute, can you weigh in? Am I missing something, or is it true that pin_access does not handle multi-via requirements?

[maliberty]

It only uses a single via. In principle it could use a double cut via - would that satisfy your DRC requirement? I haven't seen such a large std cell pin before. Is this common or just some special cell? You could dont-use such cells for now.

[maliberty]

There is some info from set_debug_level DRT pin_access 1 and you could add more debugPrint messages as needed. Such infrastructure tends to get built on demand and so far we haven't needed to deal with huge numbers of vias.

The rules can be parsed by odb but actually checking them falls to drt's gc module. The only real way to know is to look at the code or its results. If we didn't see a violation we would likely have accepted the via though we need to be sure what sort of violation is blocking the via.

[Damonan]

I did one additional check to see that multi-cuts are not being used: I simply commented out all 1cut options, and saw that the tool tries nothing at all. There is nothing obviously different format-wise about the 2cut definitions in the LEF... So I wonder how it could fail to recognize the 2cuts, other than some kind of option that prevents it. Do you have any other advice on where to go from here?

[maliberty]

If you try detailed_route_set_default_via with a double cut what happens?

[Damonan]

It still doesn't seem to do anything in that case. With 1cut available in the .lef, and set_default_via, it still goes to 1cut. When I try with 1cut commented out again, and set_default_via, it still does nothing.

By the way, I experimented with some other layers as well, and did seem to confirm that the tool can recognize multi-cuts. I found that the total number of vias in the initial pin_access dump includes multi-cuts. I also found that if I comment out 1cuts on a higher layer, the tool correctly reports the default as 2cut. This continues to make me suspicious that pin_access is not attempting to use multi-cuts.

Is it possible that this is a newer feature? I am using bazel build, so I wonder if I should try to point at a newer Docker image version? It seems like the Docker image used in the bazel-orfs repo is only 12 days old though...

[maliberty]

There are no recent changes to pin access related to multi-cut. I think you'll have to add debugging info to the tool or work with PII.