Clock Skew Issue

Hey Brad,

After looking at your response on that link, I have a few questions regarding the implementation of these methods.

You gave the following advice:

If you do use a ripple or gated clock, have no synchronous data paths going to or from the derived clock domain. Use metastability synchronization registers, handshake signals, etc. to transfer data to or from that domain. Tell Quartus not to analyze timing on the cross-domain paths. Use global routing for the derived clock to minimize skew for paths within the domain.

If you do have synchronous paths to or from the derived clock domain, you probably should add some clock uncertainty. Don't assume you are OK with positive slack on the cross-domain paths if you don't have clock uncertainty.

If you have hold violations going between domains, have the Fitter try to fix them by setting "Optimize hold timing" to "All paths".

If you still have violations and the derived clock uses global routing, try nonglobal routing. This might reduce the skew for the cross-domain paths, but it will cause some skew for paths within the derived-clock domain.

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?

How does global routing work?

I tried using the assignments-> settings and declaring the signals that are giving me these warnings as derived clocks, I gave them equivalent stats as the original clock, bc I'm not sure what stats a derived clock should have.

Basically I am still completely confused as to how to approach this problem. In the compilation report, after compiling it, in the timing analysis section, it stated that the clock skew > data dely and it gave from 2 signals giving way to 1 failed path.

In fact I'm not even sure what the cause of this error is.

If you could help to shine any light that would help, also if you'd like to see the actual code let me know.

Thanks.

Paul