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

Add REPAIR_TIMING_MAX_PASSES_PER_ITER parameters #2591

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

eszpotanski
Copy link
Contributor

This PR adds new variables for max number of repairs per iteration in rsz::repairSetup, introduced in The-OpenROAD-Project/OpenROAD#6244. It also sets the best found values for a few designs.

It adds:

  • FP_REPAIR_TIMING_MAX_PASSES_PER_ITER - max number of repairs per iteration during floorplan,
  • CTS_REPAIR_TIMING_MAX_PASSES_PER_ITER - max number of repairs per iteration during CTS,
  • GRT_REPAIR_TIMING_MAX_PASSES_PER_ITER - max number of repairs per iteration during GRT.

@eszpotanski eszpotanski force-pushed the eszpot/max-passes-per-iter-params branch from ac28d08 to 286e8c2 Compare November 26, 2024 10:23
@eszpotanski eszpotanski marked this pull request as draft November 26, 2024 10:46
@@ -69,7 +69,7 @@ if {![env_var_equals SKIP_CTS_REPAIR_TIMING 1]} {
write_eqy_verilog 4_before_rsz.v
}

repair_timing_helper
repair_timing_helper "cts"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove quotes, not needed in .tcl

@@ -287,6 +287,12 @@ IO_PLACER_V:
stages:
- floorplan
- place
FP_REPAIR_TIMING_MAX_PASSES_PER_ITER:
description: >
Maximum number of repairs per iteration during repair_timing, called from floorplan.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more magic values? Every option makes a feature twice as hard to use.

Maximum number of repairs per iteration during repair_timing, called from CTS.
default: 20
stages:
- cts
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A proliferation of the same variable for the same operation. This multiplies the number of variables... Not ideal...

Copy link
Collaborator

@oharboe oharboe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

each magic variable makes the feature twice as hard to use...

Can we make some better automatic policy here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants