How do you triage a combinational loop before floorplanning?

Short Answer

Not every reported "loop" is a mistake — some designs genuinely have intentional feedback (a self-enabling latch structure, a deliberate oscillator-like element, certain memory model constructs), so the first job is figuring out which kind you're looking at. Pull the actual netlist path the tool flagged and trace it by hand: does the signal genuinely loop back through purely combinational logic with no register in between (a real, accidental loop — usually from a synthesis or RTL bug), or does it pass through something the tool is mis-modeling as combinational when it's actually a latch or intentional feedback structure?

Technical Explanation

• Check whether the STA/PD tool has automatically broken the loop at some arc — most tools will pick an arbitrary point to cut a combinational loop so analysis can proceed at all, and that automatic break point matters: if it's in the "wrong" place, timing results through that region become meaningless even though the tool doesn't complain.
• If it's a genuine bug, this needs to go back to the design/synthesis team before floorplanning — a real combinational loop is a functional correctness problem, not something PD constraints can paper over.
• If it's intentional, make sure there's an explicit set_disable_timing or set_false_path exception documented for that arc, rather than relying on the tool's automatic (and somewhat arbitrary) loop-breaking behavior — explicit intent beats implicit tool behavior every time.
• Treat this the same as any other readiness check: the result should be a named object (the specific instance/pin forming the loop), a documented decision (intentional vs. bug), and something reproducible by another engineer from the same netlist — not a judgment call buried in someone's head.

What To Check

• Warning sign: Timing propagation is interrupted and a loop warning names unexpected functional logic.
• Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
• Correct: Trace the loop, consult synthesis/RTL ownership, repair a netlist bug upstream, or document the intentional model and exact timing treatment.

Healthy, Suspicious & Hard-stop Results

• Expected: Distinguish an intentional feedback model from an accidental netlist loop and identify any automatic timing-arc break chosen by the tool.
• Stop before floorplanning when required logic or timing coverage is missing or unexplained.

What The Interviewer Is Testing

Be ready to explain why this matters before floorplanning.

Follow-up Question & Model Response

Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”