Open oharboe opened 2 weeks ago
@tonywk What is this, wrong issue?
That's a bot. GitHub is going under a surge of bots hosted by certain people from the Russian LUMMA forums. Backed by the government, their goal is apparently to steal as much crypto currency as possible.
Post deleted
Should this be an OR issue or is it related to the setup of megaboom?
Should this be an OR issue or is it related to the setup of megaboom?
Unknown. I have the reproduction case this morning, but I don't know anything about what is going on.
Please advice.
If you want OR developers to look at then it is best to file with OR. We don't track megaboom issues.
@maliberty Can you transfer this issue to OpenROAD? I don't have the access permissions
@AcKoucher please give this high priority (a workaround or a solution)
@AcKoucher @maliberty Found a workaround, tweak initial conditions
@AcKoucher @maliberty Found a workaround, tweak initial conditions
From the megaboom PR:
I would like to see an initial diagnosis from @AcKoucher first... but yes. I hope the problem is just some existing rare problem that presents itself with some unfortunate initial conditions and that it can be solved in due course but without urgency.
It looks like there's a combination of things that make this somewhat peculiar.
Now, the actual problem seems to be that when we get to the point of placing the children of the cluster 4 in the first image - 7 in the second image after dead space filling - even with the target util variation SA can't fit the clusters in the outline. Apparently this happens, because the outline penalty never wins the fight against the boundary penalty.
However there's something going on with the wire length, because for all the steps, I see zero at the debug report (perhaps it's too small I have to check).
------ Penalty ------
Area 1.0186
Outline Penalty 0.4646
Wirelength 0.0000
Boundary Penalty 102.0848
Normalized Cost 55.1202
My first suggestion would be to try decreasing the halos as @oharboe already did or decrease the boundary penalty. @maliberty It looks like there's a lot going on, do you have some idea of what to aim first?
Thanks! Sounds like this is in good hands and well understood. No longer urgent for my part as we have a workaround.
@oharboe Ok :-) I'm investigating what is going on with the clustering so we can have a proper fix.
Another workaround I'm trying out is to save a macro placement. With a saved macro placement, I should avoid rtlmp errors due to slight changes in initial conditions, like changed PLACE_DENSITY.
write_macro_placement macros.tcl
@AcKoucher Please confirm that the fixes work on the full testcase of 1 hour
I included a faster, 13 minute, testcase here, that I produced from the full testcase with deltaDebug.py.
There is a risk that deltaDebug.py identified other bugs than the original bug...
@AcKoucher Please confirm that the fixes work on the full testcase of 1 hour
I included a faster, 13 minute, testcase here, that I produced from the full testcase with deltaDebug.py.
There is a risk that deltaDebug.py identified other bugs than the original bug...
ah, the full test-case still fails...
Can you re-delta?
@oharboe As I said in #5666 there are other problems that need to be addressed in other to actually resolve the issue. I'm investigating.
@maliberty New deltadeug: this test case takes ca. 13 minutes and fails on master:
https://drive.google.com/file/d/1klYn7s2_uJBk2Wi-vfPKK_ol8Kwv02sY/view?usp=sharing
13 minutes to reproduce:
untar https://drive.google.com/file/d/18n0z4_Bk9Gscy3RRCiU6FiNvghIb6zIG/view?usp=drive_link
Originally posted by @oharboe in https://github.com/The-OpenROAD-Project/megaboom/issues/97#issuecomment-2308988697