Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

absolute pdn offset #1213

Open
kareefardi opened this issue Jul 18, 2022 · 10 comments
Open

absolute pdn offset #1213

kareefardi opened this issue Jul 18, 2022 · 10 comments
Labels
enhancement New feature or request OpenLane 2 Scheduled for next gen OpenLane

Comments

@kareefardi
Copy link
Collaborator

Prompt

A clear and concise description of what shortcoming you feel OpenLane has.

PDN's offset is measured from the core origin. This is the way openroad api is defined. During developing a design core margin can change frequently resulting in a new PDN interface the given same PDN offset

Proposal

A clear and concise description of what you want to happen.

Using the core margin, core site dimensions, a fixed PDN offset, an offset relative to the core can be calculated at run time to maintain a "fixed" PDN offset. This can ease development of designs and maintenance of new versions of designs

@kareefardi kareefardi added the enhancement New feature or request label Jul 18, 2022
@maliberty
Copy link
Member

Why would you want PDN to be fixed if the core area is moving underneath it? You may wind up with a poor grid that doesn't cover the core area.

@kareefardi
Copy link
Collaborator Author

By "doesn't cover the core area" do you mean it would generate unconnected straps ?

@maliberty
Copy link
Member

It would connect to the straps only over the overlapping area (in the extreme they would be unconnected if there was no overlap). What is the value in having the PDN fixed in space?

@kareefardi
Copy link
Collaborator Author

In some cases a given macro is already integrated and it would be hard to change the routing of the parent design

@maliberty
Copy link
Member

Why change the core margin in that case?

@kareefardi
Copy link
Collaborator Author

If the margin was big enough, it can solve placement and routing issues in case of increase in congestion or utilization.

@maliberty
Copy link
Member

Do you mean make the margin smaller? Increasing the margin would increase congestion. I'm not sure why you don't just set it to a minimal value to start with.

@kareefardi
Copy link
Collaborator Author

Yes that's what I meant. If the old was big, decreasing it would help. Having a minimal value.
I don't know really know on the top of my head why we aren't using always a minimal margin. I think the relation between the margin, number of pins, congestion, etc.. isn't always directly correlated. I recall that I once had to increase the margin in order to get it to cleanly route.

@kareefardi
Copy link
Collaborator Author

kareefardi commented Jul 18, 2022

I do wonder if this can lead to designs with faulty PDNs which aren't automatically detected.

@maliberty
Copy link
Member

I recall that I once had to increase the margin in order to get it to cleanly route.
That sounds more like a bug. I think using a minimal value would be better than fixing the pdn grid.

@kareefardi kareefardi added the OpenLane 2 Scheduled for next gen OpenLane label Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request OpenLane 2 Scheduled for next gen OpenLane
Projects
None yet
Development

No branches or pull requests

2 participants