Honored Contributor
Honored ContributorSDC constraints are a description of how your design is supposed to work, so there are no hard and fast rules without knowing the actual design.
1) If your design treats transfers between these domains as synchronous and if they don't behave that way then the design won't work, then the design won't work(this is by far the most common case). But some systems are designed to treat them as asynchronous, in which case it's fine. For example, a user may have IP with asynch FIFOs between the domains, and so it can handle them being different domains, but the user just so happens to hook them up to the same(or synchronous) domains. In that case they could be treated asynchronous and the design will work. 2) No. I have seen cases where the user drives the same clock into two different clock pins and treat them as synchronous(I don't remember why). But in that case the source input port is different, but the true source outside of the FPGA is the same, which is why it works. Some users don't like to put asynchronous clock assignments between asynchronous clocks though. Instead, they put a false_path between any transfers that go between these domains. The benefit is if a designer hooks something up incorrectly and passes between domains but doesn't realize it, there won't be a false path on that path and it will most likely fail timing. They'll then analyze the failing path, see there is a mistake in the code and fix it. (This works most of the time but not all the time. Let's say the design has two 6ns clocks coming from different sources, so they have no phase relationship and must be treated as asynchronous. In the TimeQuest description they will have a 6ns setup and 0ns hold, and an errant path hooked up between them might actually pass timing and therefore not show up in red.)
