Timing Constraints Material

I wonder if there are additional, maybe unintended, paths between clock domains that aren't covered by the handshaking.

"Report Clock Transfers" in TimeQuest reports the number of paths crossing between domains. Maybe this number would give a clue whether more is going between domains than the paths qualified by the handshaking and the handshaking signals themselves.

The intended cross-domain paths might have false-path settings. To check for additional, unintended paths for the same domain combination, the false-path setting will need to be removed temporarily to get a path quantity shown in the table.

Even though the design is currently using the Classic Timing Analyzer, the TimeQuest "Report Clock Transfers" command will probably work well enough with whatever the QSF2SDC utility produces. Open TimeQuest and let it run that conversion when it asks (or run "Constraints --> Generate SDC File from QSF" if it doesn't ask). Then double click "Report Clock Transfers" in the "Tasks" pane.

The Classic Timing Analyzer also might be failing to report timing on paths that either need the timing analyzed or need handshaking added for them. If that analyzer considers two clock domains to be unrelated, the default settings will not analyze timing on paths between those domains. TimeQuest by default will analyze timing on all cross-domain paths until the user explicitly adds false-path exceptions for them, so TimeQuest is more likely to report a timing violation on an unintended cross-domain path.