-
Notifications
You must be signed in to change notification settings - Fork 419
High Fanout Net Thresholding in AP to Speed Up Solver #3137
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
Changes from 15 commits
3d5948d
5c3477b
edc360c
29d7390
39b5af9
bb629ab
d96d548
7075db1
362f9ea
aa13bf2
4d93870
5c5d0a0
682fe16
fbe788f
780e4ef
631616d
5d5ccb9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,13 +16,16 @@ class UserPlaceConstraints; | |
/** | ||
* @brief Use the results from prepacking the atom netlist to generate an APNetlist. | ||
* | ||
* @param atom_netlist The atom netlist for the input design. | ||
* @param prepacker The prepacker, initialized on the provided atom netlist. | ||
* @param constraints The placement constraints on the Atom blocks, provided | ||
* by the user. | ||
* @param atom_netlist The atom netlist for the input design. | ||
* @param prepacker The prepacker, initialized on the provided atom netlist. | ||
* @param constraints The placement constraints on the Atom blocks, provided | ||
* by the user. | ||
* @param high_fanout_threshold The threshold above which nets with higher fanout will | ||
* be ignored. | ||
* | ||
* @return An APNetlist object, generated from the prepacker results. | ||
*/ | ||
APNetlist gen_ap_netlist_from_atoms(const AtomNetlist& atom_netlist, | ||
const Prepacker& prepacker, | ||
const UserPlaceConstraints& constraints); | ||
const UserPlaceConstraints& constraints, | ||
const int& high_fanout_threshold); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: int do not need to be passed by reference. In fact, it may actually be slower to pass an int by reference. Turn into pass by value. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For simple types, like integers, you can just pass them directly:
We pass the other arguments to this function by const reference to prevent deep copies which are very very expensive for these types. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @haydar-c General rule: if it is smaller than or equal to the size of a pointer (64-bits) and you don't need to update it in the callee, pass by value. It avoids a pointer access to get it and hence will be faster (unless the compiler is clever enough to optimize out the pointer access, but I wouldn't count on that). If it is bigger than 64-bit then pass by const ref if you don't need to modify it. Faster than a large copy. If you need to modify it, no option but to pass by (non-const) reference. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks Vaughn! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heads up about setting the net as ignored. This does ignore the net during global placement; however, it also ignores the net when calculating the HPWL during Global Placement!
vtr-verilog-to-routing/vpr/src/analytical_place/partial_placement.cpp
Lines 14 to 34 in 8446653
This only affects calculating the HPWL during GP, the other HPWL calculations (such as post-FL and post-DP) will not be affected. I originally did this for debugging (since we do not really care if nets that we are ignoring are getting longer); however this may be a bit confusing now that this is becoming more mature. I honestly have no idea how to resolve this issue in practice. Should we even be ignoring nets when computing HPWL?
@vaughnbetz I guess this is more of a question for you. Do you see any issue with ignoring nets during the HPWL estimation. We do use this for debugging as well as part of the algorithm to estimate the quality of the placement. My gut feeling is to ignore the nets when computing HPWL since its just an estimate anyways. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a separate flag (or just inline code) to control what goes in the solver. The rest of the flow only ignores nets that are assumed to be perfectly routed on a global network. Ignoring some algorithmically selected nets in howl calculations is going to be confusing as it doesn't match the rest of the flow.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats a great idea Vaughn! I like that idea. In the solver we can ignore the nets (since it would speed up computing HPWL each iteration and it would make the value more accurate to what we are optimizing), and then when we report the final HPWL we can only ignore nets marked as global!
@haydar-c Lets not gate your change! This is something that I can add after your PR is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, sounds great!