Inserting PDN takes a lot of time

[oharboe]

Is it expected that inserting PDN (last part of make floorplan) should take a lot of time for designs that start to approach 1mm^2 in ASAP7?

It would be helpful if "make floorplan" was faster, because then it is quicker to iterate on the floorplan, after which the build can normally be left alone without human interaction for longer runs.

I ran it in the debugger and it looks like a lot of time is spent building this ShapeTree:

OpenROAD/src/pdn/src/shape.cpp

Line 637 in b99d7d2

filtered_obstructions.insert({box, shape});

Afterwards, this line seems to almost always return false

OpenROAD/src/pdn/src/shape.cpp

Line 640 in b99d7d2

return Shape::cut(filtered_obstructions, replacements);

)

I made a few fleeting vain attempts to rewrite the code, such that the common case,

OpenROAD/src/pdn/src/shape.cpp

Line 627 in b99d7d2

bool FollowPinShape::cut(const ShapeTree& obstructions,

, returning false, would not require building the ShapeTree.

[maliberty]

There could be a lot of factors. Are you using the asap7 default pdn?
@gadfort

[oharboe]

Yes.

[oharboe]

Still running, 1 hr 35 minutes...

01:35:49 /OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad -exit -no_init ./scripts/pdn.tcl -metrics ./logs/asap7/doohickey/base/2_6_pdn.json

[maliberty]

In asap7 the m1/m2 stripes introduce a ton of vias. @gadfort could help skip the add_pdn_connect for M1/M2 or would that produce an error. It wouldn't matter much for prototyping whether we have the vias or not.

[gadfort]

@oharboe @maliberty it shouldn't take that long, there has always been some inefficiency when building those obstruction sets and maybe it's a good idea to revisit how that is done and find a better solution that is faster.

[maliberty]

@gadfort for the m1/m2 via stapling you could easily treat that as one big obstruction rather than all the individual vias.

[oharboe]

@maliberty @gadfort Example of [INFO PDN-0001] Inserting grid: top taking at least 12 hours, after which I stopped it. The-OpenROAD-Project/OpenROAD-flow-scripts#779

[oharboe]

Use this pull request, The-OpenROAD-Project/OpenROAD-flow-scripts#779, then run:

make DESIGN_CONFIG=designs/asap7/mock-very-large-array/config.mk

This will first build the "Element" macro, then the top level design will be built. It is when the PDN is inserted in the top level build you will see the speedup of my hack.

[gadfort]

Element is failing placement for me. So I can't replicate, please generate a make issue_pdngen for the slow step so I don't need to figure out why placement is not working right.

[oharboe]

I'll knock this test-case into shape so that it passes on Jenkins: The-OpenROAD-Project/OpenROAD-flow-scripts#782

[gadfort]

@oharboe I think I managed to trick things to run, atleast enough to try it out. My preference (for future reference) would be to use the issue feature instead of a PR on ORFS, it just makes things harder not easier.

[oharboe]

Thank you. Noted.

PDN insertion is one important thing to fix that I wanted to cover by the test case above. I'm hoping to get the test case into master, if it isn't regression tested, it will bit-rot sort of thinking.

[oharboe]

PDN insertion is MUCH faster than it used to be, but it can still be an issue.