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

Cost function for contest (and memory limits) #25

Open
profmadden opened this issue Feb 8, 2024 · 3 comments
Open

Cost function for contest (and memory limits) #25

profmadden opened this issue Feb 8, 2024 · 3 comments

Comments

@profmadden
Copy link

Will the contest use the v2 evaluator cost function? We're working on tuning our routing tool, and want to be sure we're aiming at the right target. For the example routing solutions, the costs vary widely.

With bsg_chip, the v2 evaluator has

Number of open nets : 0
wirelength cost 58096126.3963
via cost 20876700.0000
overflow cost 41432310799597248.0000
total cost 41432310878570080.0000

Total cost is dominated by overflow, 4.14e16. The via and WL costs are e07. I think it was mentioned that the reference routes are from a pattern router, so large overflow isn't surprising, especially with the exponential cost metric.

On ariane133_51, the evaluator has

Number of open nets : 0
wirelength cost 9296578.1002
via cost 3358316.0000
overflow cost 18676.0496
total cost 12673570.1498

Total cost is 1.26e07, while the overflow costs are 1.86e04. Wire length and via costs dominate in this case.

My impression is that the first objective is to minimize overflow to avoid the exponential penalty -- but if that's kept tamed, then the competition is to minimize the combined wire length and via cost.


And a second question -- the contest test machine will have 200gb of RAM; is it possible to increase that limit? We're bumping into this on the largest test case, and an increase in the limit would be helpful.

@liangrj2014
Copy link
Owner

Thanks for the questions!

  1. As for the evaluator, the evaluator.cpp (Fixed a small bug in evaluator_v2.cpp) here https://drive.google.com/drive/folders/1VTnIFtCa6X7cRRx9xBtPDu-kHPdnhCzL is the latest version and we expected it to be the final version unless we find significant bugs.
  2. As for the RAM limit, we need to have internal discussion before making the decision. Will release our decision soon. Thanks!

@profmadden
Copy link
Author

Great, thanks -- we'll use the evaluator_v2.cpp for our internal benchmarking.

WRT memory -- we've found a way to reduce the demand for our algorithmic approach, and I think 200GB should be enough for all the benchmarks.

@liangrj2014
Copy link
Owner

Great! Then we will keep the 200GB constraint.

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

No branches or pull requests

2 participants