Router violation with proprietary PDK

[sebinho]

Hi Guys,

I am posting here regarding an issue I am struggling with regarding the detailed routing of OR.
I am using a proprietary PDK, so it is difficult for me to share a complete example of the issue.

I am constantly running into metal spacing violations on M1 with my 45nm PDK. I systematically get the same error, typically on the same net(s). Because of that, the router always goes up to the max number of iterations (64) and never finds a solution.
Here is a snapshot of the issue at hand.

You can see on the bottom orange rectangle (this is a VIA between M1 and M2), that the metal spacing is 0.06um. This violates the metal spacing rule of 0.07. M1 is in dark blue. You can see M2 in cyan in the picture below.

What I noticed is that the routing tool is able to select between 2 types of vias (on its own). Sometimes he selects a horizontal via (like the one that is problematic) and sometimes he takes a vertical via (like the one show in the upper part of the image where the 0.07um rule is respected).
The solution to the problem is quite straightforward when done manually. Simply replace the problematic via with its vertical version. But somehow the tool cannot see that.

Is there something that can be done for such an issue @maliberty ? I understand that it is not easy to debug as I cannot share my PDK . Apologies for that.
Thanks for your help.

[maliberty]

You said to goes to 64 iterations. Does drt report these violation itself or are they only seen by another drc tool?

Precision Innovations does provide paid support under NDA if that makes sense for you.

@osamahammad21 any thoughts?

[sebinho]

This is actually a violation reported by OpenROAD and also by our DRC proprietary tool.
regarding paid services, we are not looking at this track for the moment, we are first trying to find a solution and then we will see what we can do next.
Worse case those violations (always the same ones) can be changed manually provided that there are not too many

[maliberty]

Does the drc straddle the boundary of two different cells? (ie the pins are in different instances)

[sebinho]

I just checked, and in this case it seems to be indeed right at the boundary between 2 different cells (a FF and a MUX, see below).
I will rerun the tool with different settings to see if it always occurs on a boundary and let you know.

[sebinho]

I reran the tool with different settings and 1 get 1 violation for metal spacing. It is a different location in my design but once again it seems to be at the boundary between 2 different cells. See below red line for separation.

Any clue how this could be solved?
Thanks a lot

[gadfort]

@sebinho I believe the settings should be applied to: drt_via_in_pin_bottom_layer and drt_via_in_pin_top_layer. The picture above doesn't look like there is a density issue if it's access within a standard cell.

[sebinho]

@gadfort, indeed, I guess we replied at the same time. Thanks for commenting

[gadfort]

I need @maliberty to provide definitions to those unless the online docs finally have them properly defined. (from the flag itself it's not clear why there is a top and bottom layer.)

[gadfort]

@maliberty this doesn't actually explain what the flag does: https://openroad.readthedocs.io/en/latest/main/src/drt/README.html#options

[maliberty]

@osamahammad21 please improve the docs for the via in pin option

[sebinho]

@maliberty do you have any recommendations on where to look first in order to speed up the routing for a proprietary PDK?
Now that I added an extra layer of complexity (custom DEF file to specify core/die size and pins locations, custom power grid), it often crash due to not being able to access pins. Or it takes forever to eventually not solve all violations.
Should I incrementally try to simplify the technology (.LEF) file? Any other things I should look into?
My test design (very small module) goes through Sky130/freepdk45 in a matter of minutes even with a very similar DEF file and power grid…
Thanks for your help

[sebinho]

One of the things I did for the time being in order to remove the « cannot find route to pin » is to tell the tool in my stackup spec not to use metal 1 layer for routing…

these issues do not occur if I let the tool place the pins randomly around my die area…at least for the pin access, routing still takes a long time

[maliberty]

You can use -droute_end_iter to make it stop earlier if it is just stuck on a few DRCs that you plan to fix manually. You can look at the reports at the end of the iteration to get a sense of the sort of violation it having trouble with if plan to simplify.

In general the sort of rules matter a lot. Pin access is tricky to diagnose with no data. Its more of a developer tool but you are welcome to try detailed_route_debug -pa -pa_markers -pin <inst_name>:<pin_name> to get more details on a pin access problem. You give that before calling detailed_route while running in the GUI and it will show you how it is trying to access the pin.

[sebinho]

Thanks for the tips. I will try it out and let you know

[sebinho]

I did a lot of various testing.
Regarding the "pin access" issues, I tried the developer option with detailed_route_debug. This is indeed not trivial and hard to figure out what is going wrong.

What I did is drastically simplify the technology LEF file, knowing that I would get tons of DRC violations. After doing this, no more pin access issues and the router is extremely fast (like a 3-5 iterations).

Then I can add some rules 1 by 1 in the technology file, and see when it starts failing but it quickly does.
At first I thought it could be related to my power grid setup or even my custom pin placement (as changing them could have an impact on the errors received), but now I think it all boils down to the rules defined in the LEF file.

This is very tricky to debug and to find an optimum. I suppose there isn't a miracle solution. Or maybe there is something I don't grasp.

Should I have the assumption that it is possible to port any rules deck with OpenROAD?
Not sure if you have any other suggestions or what would be the best approach to have when porting a new PDK with OpenROAD?
Thanks @maliberty

[sebinho]

I can share one example of a rule that the openROAD router does not seem to apply properly.
I have a rule defined in one of my VIAs. This is a rule that must be applied when a via array is used. Here is the rule in question:

SPACING 0.34 ;                                           
SPACING 0.54 ADJACENTCUTS 3 WITHIN 0.56 ;

When we have simple vias, they will have a spacing of 0.34um. But when we have a more complex via array, it should use a spacing of 0.54um. This does not work and I can clearly see in the GDS that the spacing is kept at 0.34.

My current workaround is to set the first line 0.54 instead of 0.34 as I know those layers are only used for power routing and I can just use vias with a bigger spacing.
This issue concerns the upper layers (thick ones).

[maliberty]

Should I have the assumption that it is possible to port any rules deck with OpenROAD?

That's probably too strong a statement (eg we don't support all rules below 12nm) but for older nodes it should be possible. More rules certainly will slow down the router if they make it more difficult to find legal solutions.

@osamahammad21 am I correct in thinkin we support ADJACENTCUTS / WITHIN?

[sebinho]

thanks for letting me know, this makes sense that I cannot satisfy this rule.

[sebinho]

After lots of tickering, we do have something in place with our proprietary PDK that runs relatively fast but we are unable to be completely DRC clean.
Even if we discard the DRC rules regarding multi-cut vias, there are still a couple of rules that seem not to be understood by the tool. I am not sure we can do much better.
I would be curious to see the technology file used in a real 45nm PDK.

@maliberty Do you know if any tapeout was ever made with a 45nm? I have seen lower nodes being used with OpenROAD like GF15. Is there any publicly available 45nm technology file aside from the freepdk45 one? This one is way too simple and does not have many DRC rules. It would be a good reference to compare to.

[maliberty]

I don't know of any public manufacturable 45nm PDK. I think we are reaching the limits of what we can do without a support contract and an NDA.

[sebinho]

Makes sense, understood.
Anyways much appreciated your help.
If we want to take this further at some point, should we reach out to you from your website?

[maliberty]

Yes