dpl: draw diamond search as a per-instance outline - #11055
Conversation
Record diamond-search candidates for every cell, keyed by dbInst, instead of only for the debug instance, and clear them per cell at the start of each search. drawObjects() then unions the candidates and strokes just the exterior boundary for the debug instance plus whatever is selected in the GUI, so a cell's last search can be inspected by selecting it -- the same workflow as the negotiation search windows. Filled per-candidate boxes hid the cells underneath and, since consecutive candidates are one site apart, stacked into an unreadable blob. Pink is the one hue not already taken by this renderer. No effect outside debug mode: the observer only exists after set_debug_dpl and both call sites are already guarded. Also report the negotiation best location in absolute dbu so it can be compared against the reported search windows. Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
There was a problem hiding this comment.
Code Review
This pull request enhances the detailed placement (DPL) debugging graphics by tracking and displaying diamond search candidate regions for multiple cells, using boost::polygon to union overlapping areas and draw their exterior boundaries. The review feedback highlights potential null pointer dereferences on the cell pointer in Graphics::binSearch and Graphics::clearDiamondSearch, and suggests calling clearAllDiamondSearches() at the start of placement to prevent stale visualization data from persisting.
|
I have a memory concern. Previously we used to store the candidate list of one cell only, now we store it for every cell. That could blow up on a big design. |
do not store one odb::Rect for each instance, intead store row limits for the search, cache polygon union, and do not recompute every repaint, ignore cells with no search, clear after pause, not after Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
|
I changed it so we don't need to store an odb::Rect for every instance. Testing with a private design with 413K instances we get 4701.3 MB with debug mode versus 4643.7 MB without debug mode. |
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
make search outlines thicker, fix perforamnce issue with debug iterative mode, do not copy all instances for each move. Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
Summary
We currently still use diamond search legacy algorithm as a fall back for corner cases when we fail to legalize an instance with negotiation.
This PR reworks the diamond search debug drawing. Previously when we have a defined debug instance from TCL parameter we would draw in teal the search space. It had an issue where we would not clear the drawing even after clicking continue in debug mode:

Now it works more similar to the debug drawing of the negotiation search window. We do not need to set the debug instance from the TCL parameter, we store the search range of each instance and if we click on it we get the diamond search outline, I also changed the drawing so it is just an outline and not draw on top of the layout.

Notice we get the negotiation window there (smaller one in teal).
Type of Change
Impact
No-op, debug changes only.
Verification
./etc/Build.sh).Related Issues