Improve user-experience of macro placement

[oharboe]

Description

Untar and run https://drive.google.com/file/d/1B_0RsKZgjLowZlA7cjAqamY0c4zkseZv/view?usp=sharing

The macro placement is not great for global routing, @maliberty suggested smaller halo to improve macro placement.

Enabling RUDY in the GUI gives an error:

[ERROR GRT-0042] Pin auto_buffer_out_a_bits_address[0] does not have geometries in a valid routing layer.
[WARNING GUI-0066] Heat map "Estimated Congestion (RUDY)" has not been populated with data.

Suggested Solution

Output information that the user can use to set up better constraints for the macro placement, such as a recommended halo size. Also, the halo needs to be rearticulated to allow for a different halo of each of the distinct groups of macro types in this case.

Additional Context

No response

[eder-matheus]

@oharboe A quick comment on the RUDY error: it only works when you have at least the pin placement, that's why you got the error. Also, since we don't have the placement for stdcells, the heatmap would be very odd, with specific hotspots that don't translate to the placement that will be generated later in the flow.

[oharboe]

I think the pattern is wrong in the GUI: the button should be ghosted and ignored when the option is not available. This avoids the error message noise.

[maliberty]

@gadfort I think there is a general question about heatmap readiness. Placement density before placement is equally illogical. Do you have thoughts on a best path to a general mechanism?

[gadfort]

@maliberty maybe if the heatmaps has a couldPopulate() function that we could call so the maps could do a minimum amount of work to check if population is possible, if so enable the button, if not disable the button. Then we would just need to worry about the callbacks that would trigger a re-evaluation of this.

[maliberty]

That sounds reasonable. We would need some way to indicate a change of state (ie you just placed the design so now placement density is possible).