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.