Explain, at the edge level, why a simultaneous source edge is not counted as the launch edge in the different-clock setup analysis, and why that's conservative-correct.

Short Answer

For a capture edge at time t, the tool pairs it with the nearest launch edge strictly before t — never the edge at exactly t itself — because data launched at the same instant it is captured would need zero propagation delay through real logic, which is physically impossible. Reaching back to the previous edge gives a smaller available window and therefore the more restrictive, correct setup requirement.

Technical Explanation

Setup analysis across two clocks of different frequency or phase has to decide, for every capture edge, which launch edge actually constrains it — and the rule follows from what a setup check physically means.

• What a setup check is actually asking. Setup fails if data launched at some edge does not reach the capturing register before the next relevant clock edge, once logic delay and setup time are subtracted. The check only makes sense if there is a positive amount of time between launch and capture for data to travel through.
• Why a coincident edge cannot be the launch edge. If a source edge lands at the exact instant as the capture edge, data launched then would need non-zero gate and wire delay and still arrive by that same instant — zero available time for non-zero delay is not physically achievable.
• So the tool reaches back to the previous edge. For a capture edge at time t, the nearest source edge strictly before t gives a genuinely positive window, for example one full period of the slower clock, for data to propagate through.
• Why that is the conservative, correct choice. The earlier edge produces a smaller available time than any later, still-valid edge would, so the resulting setup requirement is the tightest one the tool could derive — exactly the direction setup analysis should err toward.
• Why a coincident or later pairing would be wrong, not just less conservative. A coincident edge gives zero window, which is not a valid physical scenario at all; a more generous pairing would understate the real requirement and could pass a path that genuinely violates setup in silicon.
• How this generalizes beyond a simple divider. Across two independently generated or phase-shifted clocks, the same reasoning applies at every capture edge in the repeating pattern — the constraining launch edge is always the nearest strictly earlier one.
• What to verify if a report looks wrong. report_timing (PT) on the path shows the exact launch and capture edge times the tool selected, which is how you confirm the pairing directly rather than reasoning about it from the clock periods alone.

Follow-up Question & Model Response

"Are there any real design situations where a coincident source and capture edge is treated as a valid launch/capture pair?"

Candidate Model Response: Yes, but only under an explicit timing exception, not under the default different-clock setup analysis — a zero-cycle multicycle path, declared with set_multicycle_path (SDC) set to zero and specifically verified by the hardware designer as a real, intended same-edge relationship, tells the tool to treat that coincident pairing as legitimate for that specific path. Outside such an explicit declaration, the tool's default behavior is exactly what protects against silently accepting a physically impossible zero-delay assumption.