Set_input_delay misunderstanding

Hold violations are restricted Fmax? I haven't seen this, but not sure how it would work. A hold violation within a domain basically means it can't run at any rate, i.e. even 1 Hz. So not sure how it would show the magnitude of failure without a negative number or something strange like that. For multiple clock domains, it's the path between domains that are of concern. Does that path get reported in both domains, so if all paths within domain A make timing and within domain B make timing, but the path from A to B fails, then both domains get reported as failing? That could work, but be confusing. The problem with Fmax is that it assumes a different frequency. For example, a clock with a 100Mhz constraint might get a report that it can run at 120MHz. But for interactions with other domains, how do they scale together? Most cases probably could be worked, when a domain is an integer multiple of the first, but there are a number of corner cases that just don't work that way. Another example might be the two registers within a domain when sampling something asynchronously. The clock period might be 5ns, but the user has a set_max_delay of 4ns on that path to give it 1ns for the metastability of the first register to settle out. If Fmax is reported as being 250MH(4ns), is it assuming this set_max_delay is still 4ns from launch to latch, in which case there is no more metastability protection? Or does it scale to 4/5ths of the previous requirement, to 3.2ns? Or does it keep it's distance from the previous latch edge, and stay at 3ns? Technically, the last one is what I would want, but there's nothing in the constraint that says that.

Slack, on the other hand, looks at your clock requirements(and other constraints) and says whether the paths pass or fail and by how much, but it doesn't assume all paths will scale together, i.e. it doesn't report a frequency different than what you asked for. It's this assumption that Fmax does that can get tricky.

We're definitely going down the rabbit hole of corner cases, but to fully rely on a methodology it needs to cover all the cases. And even with slack, I get users asking asynchronous hand-shaking corner cases that I don't think it can handle, but that's another thread...:)