TNS_END_PERCENT and hold cell problems in CTS

[oharboe]

I copied TNS_END_PERCENT=100 from another project when I first set up mock-array. Lots of projects use TNS_END_PERCENT=100, so it seemed like a good idea: #1347

TNS_END_PERCENT=0 means repair only the worst path, TNS_END_PERCENT=100 means repair everything. https://github.com/The-OpenROAD-Project/OpenROAD/blob/b31a3b960dfa4f0cf387e53d6218e9e8f89d3aa8/src/rsz/README.md?plain=1#L193

⚠️ WARNING: TNS_END_PERCENT is default 5 in ORFS, but 0 in OpenROAD

Later on I ran into problems with hold cells overflowing placement in CTS and later on global route getting stuck, which I should expect when I set TNS_END_PERCENT to 100?

TNS_END_PERCENT is default 5,

OpenROAD-flow-scripts/flow/Makefile

Line 104 in 3c5adbe

export TNS_END_PERCENT ?=5

Hold violations are tricky from a couple of perspectives for beginners:

• They can originate in the clock tree and timing constraints. Understanding .sdc constraints and clock trees isn't done in a day...
• It is hard to debug CTS and global route if they "run forever" and it breaks CI flows
• Debugging global route congestion is not easy

If I understand correctly: TNS_END_PERCENT=5 will cause CTS and global route to pass, but the hold violations will be presented as timing violations in the static timing reports?

Timing reports in the GUI are reasonably friendly for beginners. When setting up a flow, the concern of "fixing the hold violations" is nicely separated, just like setup violations is a nicely seperated concern.

Separating concerns, fixing things one at the time before one unederstands everything, makes it much easier for beginners...

TNS_END_PERCENT removed from mock-array in #1346

Perhaps TNS_END_PERCENT should be default 0 in ORFS too?

[oharboe]

This was discussed in some length in #1347