Hello community, I'm writing here because we are experimenting with openroad and a commercial PDK, to test its operation and performance. All was Ok until the detail routing step (particularly, the pin_access). We have tried to use "detailed_route_debug -pa" command to debug the problem, but it's too detailed and we didn't understand directly what the little crosses assignment mean. What the "pin_access" error exactly means? And how we can understand exactly what is the problem encoutered here? We have the impression that our track information was not well defined, and the tool can't find any valid access to those particular pins. Do you have any suggestion for a correct track definition? Maybe @Matt Liberty or @Tim Edwards might have a clue about that. FYI, for the offset track value, we took the half of the pitch defined in the LEF file for each metal layer, is that Ok? (the offset value is not present in the LEF file). The error is the following:

[ERROR DRT-0073] No access point for U_DSP_TEST_logic/U_Postprocessing/_503_/d.

[ERROR DRT-0073] No access point for U_DSP_TEST_logic/U_Postprocessing/_504_/d.

[ERROR DRT-0073] No access point for U_DSP_TEST_logic/U_SignalProcessing/_1382_/d.

[ERROR DRT-0073] No access point for U_DSP_TEST_logic/U_Preprocessing/_340_/d.

[ERROR DRT-0073] No access point for U_DSP_TEST_logic/U_Preprocessing/_356_/d.

[ERROR DRT-0073] No access point for U_DSP_TEST_logic/U_Postprocessing/_519_/d.

Thank you in advance. Best Regards, Rodrigo Iga

Pin access is trying to figure out how it can drop a via onto a standard cell pin in a legal way. The 'little x' are where it is trying to put the via. Try adding '-pa_markers' to see what DRC errors are being generated. You can also use '-pin U_DSP_TEST_logic/U_Postprocessing/503:d' to focus in on the first failing pin.

Hi Matt, thank you very much for your answer. After activating the debug as you described, I'm seeing that the tool is always trying to put the via in this direction and never turns it, in order to have the metal1 (in blue) vertical and the metal2 (in red) horizontal. How can I enable that the tool try to turn it? Maybe I have a bad (or incomplete) definition of the vias in my techlef file? Thank you very much again. Best Regards, Rodrigo Iga

We don't rotate vias. If you need a rotated via then you should define it in your tech lef.

Thank you Matt. Yes, the tool tries several vertical positions at the same horizontal coordinate (in the middle of the two red tracks), so it fails with all the trials. Do you think any change to the track definition could work also (as well as the rotated via definition)? In any case, with the debug option you show me, we can decide better what to do to find a solution. Many thanks again! Best Regards, Rodrigo Iga

@Rodrigo Iga: I think most PDKs define all rotations for vias as via definitions in the technology LEF file. If not, then I guess that some tools generate their own rotated vias from the existing definitions. However, doing so manually is not particularly difficult or time-consuming. Just look for each via definition, look at the rectangle defined for each of the metal planes. If there's just one via defined, then the metals are probably in the "preferred" direction for each metal plane. Copy the via 3 times, changing the name (I add a "hv", "hh", "vh", or "vv" suffix to indicate the longer direction of the bottom and top metals as "horizontal" or "vertical", respectively), and then reverse the X and Y coordinates of the top and bottom metal layers. Note that that's not just "rotating the via", but separately rotating the bottom and the top to create all four possible orientations.

I just checked, and both via rotations are already defined.

It's possible that the via rotation isn't the problem. In your screenshot above, the via is not just not rotated, it's also nowhere near the route grid intersection. At least that's what it looks like in the screenshot.

if on-grid fails then we try 1/2 grid or other locations. The image shows just one step in the process so its hard to debug

Hi Matt and Tim, The tool tries on-grid, 1/2 grid, middle of the port vertically and horizontally, and never find a valid position, even if rotating the via should be ok. Do you know if those validations are made using every via defined in the LEF (all the combinations)? Or it does it only with the first declared via?

Can you tell if there should be a valid location for that via or if there is just no way to use that via and another is needed? We do have via selection that tries to pick the 'best' vias to try. We used to use two vias but I think a fallback for more was added but I'd have to check the code

Hi Matt, Yes, I think that the ongrid position of metal(red) and the middle (and ongrid) of metal(blue) should work, but only if the via is rotated (I checked the LEF file and all the via combinations are declared). That's why I think the tool is not trying all the via combinations.

Does this tech use a via map?

All the via definitions are normal, like the following: VIA ViaName DEFAULT LAYER metal1 ; RECT xx yy zz bb ; LAYER via1 ; RECT xx yy zz bb ; LAYER metal2 ; RECT xx yy zz bb ; RESISTANCE RR ; END ViaName

I don't think there is any specific output to just enable. You would have to add some to debug further.

From October 2023

You should update

Ok, thank you very much.

the via fallback was added last Nov

Ahh ok, sorry for that 😞

np I should have asked that first

Thank you again for your kind help 🙂

Btw what process node are you looking at? We did 65lp for academic use a while back

We are trying to adapt a 180nm commercial tech node.