Honored Contributor
Honored ContributorRight. I was saying "clock Tco" to help with understanding, i.e. when the clock comes out. You're right that it's probably not defined, and just data in relation to the clock is defined, so it might be more confusing.
So the setup analysis is identical with identical slacks, which is correct. Personally, I don't like Fmax and avoid using it. It only analyzes paths within a domain, as it's often not clear how to speed up the Fmax of separate clocks. When the clocks look identical, like in this case, we could say they speed up identically, but there are cases where there are transfers between domains that just don't fit into the idea of Fmax. As a result, Fmax just reports when the launch clock and latch clock are the same. (This path is still analyzed correctly in setup analysis, and if it failed it would show up there, so it's not like it's being missed.) So when we use a virtual clock, this path isn't part of the Fmax calculation, but it is when we use the same clock going into the FPGA. Makes sense and I believe correct. (Again, Fmax is not something TimeQuest analyzes and can correctly be done within multi-clock designs. It was added because a lot of people asked for it, especially small CPLD designs. I really think it's worthwhile to ignore Fmax and get in the habit of relying on slack, since this is the real metric for static timing analysis)
