[Draw][Breakpoint] Fix debug breakpoints to work in placement and routing

[haydar-c]

This PR fixes the debug breakpoint so that breakpoints are triggered under the intended conditions in both placement and routing.

• Previously, the router iteration breakpoint was not triggered correctly because the counter was not being updated properly.
• In addition, if placement breakpoints were still active during routing, none of the routing breakpoints would trigger since they weren’t being guarded against.

Both issues are addressed in this PR.

Related Issue

See comments in the PR #3278

[AlexandreSinger]

LGTM, so long as the feature works locally!

[vaughnbetz]

Thanks! One last thing to do:
To confirm none of this code slows us down, please run P & R with #NO_GRAPHICS and with graphics compiled in (but --disp off) and compare cpu time. You could just do one reasonably large design in a controlled runtime environment (e.g. your own machine or in a terminal on wintermute if load on it is low).

[haydar-c]

Based on comments, I ran the largest 2 VTR benchmarks on my desktop and putting CPU time comparisons here.

Build: No Graphics

Circuit	Normalized Placement Time (With Change / Without Change)	Normalized Routing Time (With Change / Without Change)
mcml.v	1.001724667	1.005574136
LU32PEEng.v	1.009246933	1.001697073

Build: With Graphics (--disp off)

Circuit	Normalized Placement Time (With Change / Without Change)	Normalized Routing Time (With Change / Without Change)
mcml.v	1.008656351	1.015185602
LU32PEEng.v	1.016414734	1.005959983

The latest change shows a small increase in runtime, but it’s marginal. I’ll defer to the reviewer on whether we should optimize it for CPU time.

[vaughnbetz]

Thanks Haydar. Both columns are labelled normalized placement time. Is the second one meant to be routing time?
These look close enough (and hopefully the second one was checking the router).

[haydar-c]

Yes, the second columns is meant to be normalized routing time. Sorry for the confusion, updated now.