Hi everyone. I'm trying to run detailed route on a design, but openroad is failing with the error message "DRT-74 No ap for PIN/clock". Placement & global route all seem to have gone ok with no errors. Does anyone have any ideas where this kind of error might be coming from or where I should look to debug it? I assume openroad is having issues accessing a clock pin on some cell, but I don't know how to tell which cell is inaccessible (or if it's the top-level pin for the module perhaps?). Hopefully it is just something like a pin being directly under a power bus, and I can just move the PDN offset slightly, but it'd be helpful to know where on my layout the issue is.

is possible to share your source file

Sure! I'm actually using openroad directly, rather than openlane or the openroad flow scripts, and I'm using a different PDK. I'm just trying to run a very simple design through openroad manually, to get a better understanding of how openroad works & test the new PDK. The design happily completes if I use the openroad flow scripts, it's just this manual method that is failing for me. I've attached the script I'm feeding openroad.

have followed steps for adding new PDK in openroad flow?

I got it working! It seems like the auto_place_pins was adding the pins too close together, and that was causing the access violations. I placed then manually further apart and detail routing is currently running happily

ok.. don't have any issues right?

Nope, all done. Sorry to have bothered you. I did follow the the new pdk instructions for openroad flow and it worked flawlessly, streaming out GDS for our process completely happily, which is really a testament to Openroad. I just wanted to try the manual approach too for my own edification.

you're welcome

I'm using the 180nm, 1.8V technology from Towerjazz. It seems to be working really well so far! Unfortunately it is VERY much a private PDK

ok.. thanks for update

@User Great to know you were able to add and test a new PDK using the OpenROAD flow? Did you use the doc link here to do so? https://openroad.readthedocs.io/en/latest/contrib/GettingInvolved.html#contributing-open-source-pdk-information-and-designs

@User it should be noted that the timing setup is not correct. You are using min and max for libraries of two different characterization points. The -min and -max are only meant to be used for libs at the same characterization point. You should either only use 1 lib or look into setting up multiple corners. There was a discussion of this on https://github.com/The-OpenROAD-Project/OpenLane/issues/671

@User Thank you for pointing that out - I'd clearly made the same mistake as the original person in that thread & misunderstood how openroad's read_liberty command works. I hadn't gotten to properly looking at timing analysis yet, but I imagine you've just saved me a bunch of tearing my hair out

@User I don't think that there's anything stopping you from using a double-cut via by default. I haven't tried using double-cut vias, but from what I know of the code, it would be handled just like a normal via. The routability may be slightly worse because of the vias blocking more space, but that shouldn't be a problem if you just tweak the routing parameters slightly (or it may even work out-of-the-box). When it comes to via selection for detailed routing, the router is lazy. It essentially picks the first available via in the tech LEF for the respective cut layer and then only uses that via. This can be overridden by setting the

OR_DEFAULT

LEF58_PROPERTY to a specific via. This is because via selection has been "good enough" and hasn't typically been a blocking item for the kits we support, whereas design rule violations and other items have been. It is rather unusual to have a kit that does not offer single-cut vias, so this issue doesn't even come up that often. In a typical lithographic-aware routing flow (which OpenROAD does not currently have), the strategy is usually to route with single-cut vias until there are no design rule violations, then make a best-effort to swap single-cut vias to double-cut vias without introducing rule violations. I don't have any hard numbers, but from academic designs I've done we usually see a 9:1 or 10:1 ratio of double-cut to single-cut vias after via swapping. Professional designs might be even more than that because it helps with reliability and variation. Is there a specific problem you encounter when using a tech LEF that only has double-cut vias? What modifications do you have to make?

@User, thanks so much for the really detailed response. I'm glad to hear that OpenROAD in theory should support double cut vias, hopefully that'll mean I can just get my plain technology lef working at some point. All the vias in my PDK are structured like this one, which connects metal1 to metal2 through the via2 layer:

VIA VIA2_2CUT_E DEFAULT
LAYER METAL1 ;
 RECT -0.3 -0.3 0.9 0.3 ;
LAYER VIA2 ;
 RECT -0.2 -0.2 0.2 0.2 ;
 RECT 0.4 -0.2 0.8 0.2 ;
LAYER METAL2 ;
 RECT -0.3 -0.3 0.9 0.3 ;
 RESISTANCE 5 ;
END VIA2_2CUT_E

(The exact dimensions and layer names there are changed because I don't want to fall afoul of our NDA with Tower) However, this failed on the detailed route step with the message

[ERROR DRT-0234] VIA2 does not have single-cut via.

I'm specifically running the openroad command

detailed_route -guide /tmp/route.guide -bottom_routing_layer METAL1 -top_routing_layer METAL3

where route.guide was generated by the global router (you can see the full script I'm using above, but I get exactly the same error if I use the openROAD-flow-scripts approach). That error comes from line 74, in OpenROAD/src/drt/src/io/io_parser_helper.cpp, which to me looks like something in openroad is misunderstanding which layers the via connects, but I'm not sure. To fix the issue and run detailed routing, I'm currently using the somewhat kludgy workaround of editing the tech lef to change all my vias into single cut versions. Specifically, I'm just combining the two RECT lines on the VIA2 layer, so that that section reads

LAYER VIA2 ;
 RECT -0.2 -0.2 0.8 0.2 ;

(ie I think I'm just taking the bounding box, if I'm reading the LEF specification correctly). That tweak to the vias makes detailed route run happily.

Oh, yeah it looks like the router doesn't like anything but single-cut vias. I don't know off the top of my head if that's a hard limitation or if that's just to prevent bad behavior. One method is definitely to just edit the LEF to remove the extra cut in the vias before detailed routing, then put them back in before GDS export. You would want to make sure it passes DRC. Another option is to just remove the error from the source code and see what happens. I'd imagine that it might take a few other changes in the code to make sure that double-cut vias are used but it definitely seems possible. Another hacky option is to set

cutNum

on like 68 to 1 so that it thinks that all vias are single-cut vias.

Hi @User - I just got access to some commercial tools to run DRC, and I thought you'd appreciate knowing that OpenROAD is generating DRC-clean output in the Tower 180nm process we use, even with the workaround I have to do with the vias. (Specifically I tweak the LEF file for Openroad, and then use the original LEF in Klayout so it all streams out okay.) I was getting weird errors where detailed route would construct nonsensical vias, with the via cut misaligned with the metal below, but fixed that with the

-disable_via_gen

tag to the detailed route command. Honestly I'm really impressed with OpenROAD, it's some remarkably capable software you've made. Thanks for helping me out!

Glad to help 👍