derived clock versus clock enable

An advantage of a clock enable over a divided-down clock is that the clock enable does not cause clock skew.

In the Classic Timing Analyzer, the divided-down clock produces messages like these unless you have a clock setting assigned to the divided clock:

--- Quote Start ---

Warning: Found 1 node(s) in clock paths which may be acting as ripple and/or gated clocks -- node(s) analyzed as buffer(s) resulting in clock skew

Info: Detected ripple clock "div_by_2_dff" as buffer

--- Quote End ---

If you assign a clock setting to the divided clock to tell Quartus you did it on purpose, the warning goes away, but the skew issue does not go away.

The recommended choices from most to least preferred:

Do not use ripple or gated clocks. Instead use clock enables or PLLs.

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.

--- Quote Start ---

2) using a clock enable and set a multicycle constrain

--- Quote End ---

what is this multicycle constrain ??

I also need to divide 16Mhz clock to 500Khz currently I made 4bit counter (count to 16) and then connected counter output to this global clock network and quartus shows this warning about clock skews and so on.

I tried to use PLL but with PLL I can lower clock frequency just to 10Mhz :(

what is the right way for clock division ??

@Epis:

See page 6-34 at Quartus II Version 7.1 Handbook or search for "multicycle" in this PDF.

@Brad:

Thank you for your answer.

I am still wondering about the create generated clock sdc constraint.

Am I wrong if I say this:

I have a divided clock clk_div. I constrain it correctly with TimeQuest. I provide clk_div to the fast global clock network.

1) My Desing will be faster than the clock enable version because I don't have the delay of the (very) high fanout of the clock enable signal, which can slow down the design (can it?).

2) My Design is reliable.

(When not for what do I need the generated clock constraint)

Can you suggest good literature for this problem?

Best regards,

Axel

--- Quote Start ---

I have a divided clock clk_div. I constrain it correctly with TimeQuest. I provide clk_div to the fast global clock network.

...

2) My Design is reliable.

Can you suggest good literature for this problem?

--- Quote End ---

Whether you have a generated clock in TimeQuest or a derived-clock setting in the Classic Timing Analyzer assigned to the divided-down clock, the fundamental clock skew issue still exists. I don't know of literature on the subject. I just know you need to be careful when timing analysis is comparing a clock skew to a data path delay.

Global routing is thoroughly characterized, so the timing analysis is very accurate for the small skew within a clock domain on a global. But there are uncertainties in the timing when the clock skew is from something other than global routing. The timing analysis is using all numbers at the slow PVT extreme or all numbers at the fast PVT extreme (depending on whether you choose the slow or fast model for timing analysis), but the numbers probably are not all at the extreme for a given path at your particular process, voltage, and temperature combination. The timing analysis has to compare the clock-path delay to the source register, the clock-path delay to the destination register, and the data-path delay between registers. The clock skew is the difference between clock-path delays. Will the clock skew be a little faster compared to data delay than the extreme numbers say? Will it be a little slower? With today's timing models for FPGAs (not just Altera FPGAs), you don't know. That's beyond the scope of slow-model and fast-model analysis.

Quartus provides clock setup uncertainty and clock hold uncertainty settings for either analyzer. Cross-domain clock skew between a divided-down clock (even if on a global) for one register and another clock for the other register is one of the cases where I recommend adding some uncertainty, but I can't tell you how much. Most people don't bother. Most people don't think about it in the first place. Some people assume guard bands in the timing analysis take care of it, but I don't like that argument because those guard bands are meant to cover other uncertainties--they weren't necessarily intended to cover this one. To be proper you should make an allowance for the skew-vs.-data-delay uncertainty yourself.

It's better to avoid a divided-down clock in the first place unless you make it global and have no synchronous cross-domain paths so that this uncertainty isn't an issue.

--- Quote Start ---

1) My Desing [with a divided clock] will be faster than the clock enable version because I don't have the delay of the (very) high fanout of the clock enable signal, which can slow down the design (can it?).

--- Quote End ---

No matter what the n value for a divide by n, the clock enable paths have to operate in a single clock cycle. As I've said at http://www.alteraforum.com/forum/showthread.php?p=2255#post2255, nonglobal routing might be better than global even for a high-fan-out clock enable because there is a big delay associated with the global buffer. Try both global and nonglobal to see which gives better slack.

The clock enable might not be as high a fan-out on a single signal as you would expect from the RTL. Synthesis tools tend to include other logic in the clock enable in addition to what is directly implied by the HDL "if" statement for the RTL clock enable. That's why you often see a large number of clock enable signals in the "Control Signals" table in the Fitter compilation report.

If you do have a timing problem from the fan-out on a clock enable, replicate the source of the clock enable. There are multiple ways to do this ranging from letting the tools do a brute-force replication without regard to where the clock enable destinations need to be placed to a manual replication in the RTL that intentionally groups the destinations according to where they will be placed on the device.

I have a similar problem. I apologize in advance if the answer is in a previous post, but I'm kinda new at this game so I might not have recognized it. Here's my problem:

-I'm using Quartus 7.1 with Classic Timing Analyzer for a Stratix II design.

-I have a 150 MHz. clock which is divided by a simple f/18 state machine yielding an 8.3 MHz. derived clock

-I have a collection of logic being clocked by the 8.3 MHz. derived clock, with no synchronous data paths into or out.

-The timing analyzer is reporting setup violations based on the assumption that the available setup time is 6.667 nsec., while in fact the allowable setup time withing this slow clock domain is 18 times that.

-Based on the previous posts, I would be wise to eliminate the derived clock, but assume I can't and must deal with it.

I'm thinking I can fix this with a simple multicycle assignment, but I can't for the life of me figure out how. Can somebody please suggest the proper form of the multicycle assignment that will fix this problem?

Thanks,

Bruce

Bruce,

Because you have no synchronous paths crossing into or out of the 8.3 MHz domain, you should be fine with the divided clock. Make sure it is on global routing, which the Fitter is likely doing automatically. Check the "Control Signals" table or the "Global & Other Fast Signals" table in the Fitter compilation report to see whether global routing was used. There's also a compilation message for it. Also make sure the 8.3 MHz clock is driven by a single register, not a combinational signal fed by the state machine state bits.

You would use a multicycle setting if you had a clock enable that is asserted one clock cycle at a time every 18th clock cycle of 150 MHz. With a divided-down clock, you can use a clock setting assigned to the 8.3 MHz clock node. Create the clock setting at "Assignments --> Timing Analysis Settings --> Classic Timing Analyzer Settings --> Individual Clocks". Assign the clock setting to the clock node name listed in the "Control Signals" table.

If you did have synchronous cross-domain paths, you would need a derived-clock setting with the divide by 18. You would leave blanks in the "offset from base absolute clock fmax" and "clock phase shift" fields so that Quartus would calculate the actual offset between the 150 MHz base clock and 8.3 MHz derived clock.

Because you have no synchronous cross-domain paths, it is OK to use an absolute clock setting with the 8.3 MHz entered directly. With the default of "On" for "More Timing Settings --> Cut paths between unrelated clock domains", there would be no need to use "Cut Timing Path" in the Assignment Editor to prevent timing analysis on any asynchronous cross-domain paths.

Brad,

Thanks for the advice. If I understand correctly, I need to have a clock setting entered for the 150 MHz clock. Then when I create a related clock setting for the 8.3 but do not enter an explicit offset or phase, Quartus will calculate the offset for me based on the timing of the counter used to generate the 8.3 and use that in timing analysis.

But in my design, the 150 MHz. is not an independent clock. It is being generated using a 6x output of a PLL driven by an independent 25 MHz. clock. So there isn't a clock setting for the 150; rather its timing is being calculated by Quartus based on the settings of the wizard-generated PLL megafunction. What then do I use as the base for the related 8.3 clock setting? I can't relate it to the 25 or I'll be missing the information derived from the PLL.

Bruce

With a PLL, you usually do not need to create a clock setting for the PLL input or any outputs because those are created automatically by the Classic Timing Analyzer. It's OK though to assign a clock setting to the device pin for the clock input to the PLL. (Don't assign a clock setting to a PLL output. That wasn't supported by past Quartus versions and could cause nonobvious problems. I doubt that support for it has been added.) You can assign a 25 MHz absolute clock setting to the clock input pin to match the PLL MegaWizard setting and create a derived-clock setting that divides by 3 for assignment to the 8.3 MHz clock node. Quartus will account for the PLL when analyzing synchronous cross-domain paths.

But as I said before, it's ok to use an absolute clock setting of 8.3 MHz on the divided-down clock if you have no synchronous cross-domain paths. If you use an absolute 8.3 MHz clock setting, you don't need a clock setting for the 25 MHz PLL input as a reference for the 8.3 MHz clock setting.

OK - so I tried your suggestion and it did pretty much as you said. However, something is still bothering me.

My test design does the following:

-clk25 driving a PLL

-PLL multiplies x 6 to form clk150

-counter divides 150 by 19 to make clk8 (7.8 is closer to 8 than 8.3)

-add clock setting for clk25

-add derived clock setting for clk8 (*6/19, phase unspecified)

-do sequential logic within clk8 domain

-include a sequential path launched by a register in the clk150 domain and latched by another in the clk8 domain

To my wonder and amazement, the timing analyzer figured all this out and I ended up with no warnings or errors.

What is bothering me is that the offset between clk150 and clk8 calculated by the TA was 4 nsec. which I'm thinking must be the worst-case delay between clk150 and the divider bit acting as clk8. The cross-domain path passed because 4 nsec. was enough setup time for the path. But the 4 nsec. could certainly be a lot less and probably would be under normal conditions of PVT. So what would really be needed here for a valid solution is to have the timing analyzer consider the smallest possible delay between clk150 and clk8 edges because the cross-domain path must sneak into this slot.

Does this make any sense?

Bruce