Clock Skew Issue

Why are you doing a ring oscillator? If you're trying to make a lower speed clock, use a PLL or a clock enable. A ring oscillator is going to have a lot of variation. Data delays can vary over PVT by quite a bit, let's say 50%. That means your oscillator's frequency can vary by 50%. That's generally not very useful.

As for clock skew, if the final clock output of your ring oscillator gets onto a global, then the actual skew to all the destinations will be negligible. In fact, if it doesn't get on a global, the actual skew is not going to be a problem, at least as far as everything it's driving. But if there are any paths who transfer data between this ring oscillator's clock and a clock that is not created by logic, then you will have large amounts of skew. You've basically added a large delay to your clock line, so it is out of whack(i.e. skew) with any other domains it might have to interface with.

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

--- 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.