The-OpenROAD-Project
pdn creating short between macro rings and core rails
@kareefardi the tapeout is this week so likely next week it could get some attention
@arlpetergadfort can you prioritize this?
Sure, I'll take a look at it this afternoon.
@arlpetergadfort can you prioritize this?
Sure, I'll take a look at it this afternoon.
@kareefardi what version of OpenROAD are you using?
When I run this I get:
There is no short.
Hey. Sorry I have only seen your reply now. It's was the same version of openroad bundled with OpenLane at the time (I don't which one exactly) Perhaps it is fixed in recent versions. I will test it and let you know
I am still getting a met4 short at the top left corner of the macro. OpenROAD version is 4a99e88667b0840531ca0096c4fa0da8f80d6cb1 I am not getting the same results for met5 in the screenshot in the first post. It is a little bit further to the left as shown below
The version that I tried is the one bundled with openlane and it looks like it's about two weeks old. were there any fixes done to pdngen in that period ?
Is there a reason your halo has negative values for the vertical? i.e. -11 vs 11?
It is needed in order to have met4 vertical stripes at the top level enter the macro and connect with the macro on met5 in the rings. Unless that changed, this is currently the only way I know that can connect top level stripes with a macro ring in which both the macro and the top level are using all the metal layers
It's the cause of the shorts. I've added a guard against that, but I'm not sure if this will break what you intend to do. It seems like you are hacking your way around a limitation and a better solution would be to figure out what is missing and add that into PDNGEN.
We have always used a negative halo and currently some designs rely on that. It used to be that PDNGEN wouldn't attempt to connect to any metal layer in a given macro if that layer has any obstructions in the macro, that don't necessarily interfere with the macro power pins. Hence, negative halo was used to force PDNGEN to enter a macro. However I believe that is not the case anymore. Is that correct?
We have always used a negative halo and currently some designs rely on that. It used to be that PDNGEN wouldn't attempt to connect to any metal layer in a given macro if that layer has any obstructions in the macro, that don't necessarily interfere with the macro power pins. Hence, negative halo was used to force PDNGEN to enter a macro. However I believe that is not the case anymore. Is that correct?
This is the general form of the problem. The usual pattern is the need to connect to a macros ring with both the top level and the macro utilizing all metal layers. and hence the top level pdn stripes would be blocked from entering the macro at all
At the moment, the halo is getting incorrectly applied to obstructions and pins and that is the problem. If your setup works for you, then it works, there is no reason a negative halo is a problem (except that the application to pins and obs is currently wrong and will be fixed). I feel like there should be a better solution, but that can be a different issue.
Ok so if I understand correctly negative halo was not applied correctly. This will be fixed (or already is fixed now). Negative halo by itself is still a valid parameter for PDNGEN. Is my understanding correct ?
Yes, negative was applied incorrectly, the fix has been merged to OpenROAD (https://github.com/The-OpenROAD-Project/OpenROAD/commit/cb3acc68084046d5b343da32c7d3ea16a6e82db9) please try the head of OR. When I run yours, it appears to work, but you will know if connections are happening correctly.