--- Quote Start ---
I am in fact using ripple/gated clocks.
How do I determine if the signals are synchronous or not?
How do I determine cross-domain paths?
--- Quote End ---
A cross-domain path is one where the source and destination data registers have different clocks. For ripple/gated clocks, I was referring to the particular case where one of the registers uses the ripple or gated clock and the other register uses a different clock (most likely the base clock used to create the ripple/gated clock, but could be another clock).
With the Classic Timing Analyzer, you can do list paths on a cross-domain data path, expand the lines in the Messages window System tab, and look in the clock skew portion to see how the ripple/gated clock is causing the skew problem. TimeQuest in version 7.1 does not show the skew the same way, but you can see the difference between the clocks for the source and destination registers if you use "-detail full_path" for report_timing. There are ways to guess which paths are cross-domain paths without having to look at the details of the individual paths to find out, but I don't have time to go into that now.
If you intended that cross-domain data path to meet the setup and hold requirements at the destination register so that the register is updated reliably at a particular clock edge, then that is a synchronous path. Some of the options to design for this path as an asynchronous path are metastability registers in the receiving clock domain (generally a solution for individual signals, not buses), handshaking to indicate to the receiving domain when the data is known to be latched in correctly (good for buses between domains), and a dual-clock FIFO, which itself is designed to handle the crossing between asynchronous domains properly. If none of this makes sense, you might be able to find something about it in a digital design text or by searching the web.
Honored Contributor
