Add clock uncertainty¶
From this alteraforums post:
Ripple and gated clocks cause clock skew for cross-domain data paths. If there are synchronous cross-domain paths, this skew affects timing.
All the clock-skew issues described below are avoided by following design guidelines #1 and #2. If these clock-skew issues concern you, then follow the first two guidelines.
For each data path, the clock skew makes the timing worse for clock setup and better for clock hold or vice versa depending on whether the source register’s clock or the destination register’s clock has the longer clock-path delay. The clock skew makes it more difficult to achieve positive slack on both setup and hold simultaneously. This consideration applies regardless of the on-die-variation considerations that follow.
If you have synchronous data paths to or from the derived clock domain and need your design to be extremely reliable, you probably should use clock uncertainty settings to make an allowance for the on-die-variation uncertainty in the timing analysis. In TimeQuest, use set_clock_uncertainty. Don’t assume you are OK with positive slack reported for the cross-domain paths if you don’t have clock uncertainty settings.
The clock skew caused by ripple, gated, and nonglobal clocks is not fully accounted for in the timing analysis. Unless the timing analysis includes on-die variation, the timing analysis uses all numbers at the slow process/voltage/temperature extreme for the slow model and all numbers at the fast PVT extreme for the fast model. The actual numbers in your device 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. At your particular PVT between the extremes, will the clock skew be a little faster compared to data delay than the extreme numbers say? Will it be a little slower? Without accounting for on-die variation, you don’t know. That’s beyond the scope of slow-model and fast-model analysis regardless of the FPGA vendor.
On-die variation matters when there is clock skew from logic or nonglobal routing in the clock paths. More specifically, the on-die variation matters for the portion of the clock paths that is not common between the source and destination registers. If the source and destination registers are in the same derived clock domain, then only nonglobal routing after the logic driving the derived clock matters (for example, nonglobal routing driven by a divider register or by a clock mux). Using global routing for the derived clock will prevent skew issues for data paths within the derived clock domain. The skew problem with ripple and gated clocks is usually in synchronous data paths that cross to or from the derived clock domain. These paths could be between the derived clock domain and the associated base clock domain, or they could be between two derived clock domains.
Until recently, on-die variation in FPGAs was not modeled or analyzed. This hasn’t been necessary for designs using global clocks without logic in the clock paths; the guard bands have been good enough to cover the variation. It matters for data paths with clock skew caused by ripple, gated, and nonglobal clocks with significant clock path delay that is not common between the source and destination registers; the guard bands can’t cover every possible design with such clocks.
With newer silicon technologies, advanced timing modeling and analysis is more important than in the past for all designs, not just those with skew on ripple, gated, and nonglobal clocks. The timing models for the 65 nm families (Cyclone III and Stratix III) account for at least some of the on-die variation, and this variation is included in the analysis by TimeQuest. The Quartus II compilation messages say that the timing models for these families are still preliminary in version 7.2 SP3. It is reasonable to expect more thorough accounting for the on-die variation in the final models. That should provide very accurate timing analysis for the vast majority of designs even if they have ripple or gated clocks. Even in the future for device families that have final timing models accounting for on-die variation, however, it will probably be wise to include some additional clock uncertainty for synchronous cross-domain paths to/from derived clocks (or follow design guidelines #1 and #2 to avoid these paths altogether) in designs that must be extremely reliable.
Clock uncertainty settings add the uncertainty for all data paths going from the source clock domain to the destination clock domain identified in the setting. Define the derived clock domain as a separate clock domain for timing analysis. In TimeQuest use create_generated_clock. For TimeQuest, you need to create the generated clock anyway if the derived clock is a ripple clock. For either a ripple clock or a gated clock, the separate generated clock will allow you to apply the clock uncertainty to only the cross-domain paths.
I can’t tell you how much uncertainty to add. 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. Those guard bands are meant to cover other uncertainties--they weren’t necessarily intended to cover this one. Guard bands couldn’t cover all possible ripple-clock and gated-clock configurations anyway; that would require guard bands that are far too conservative for most designs. Some device families are supported by the TimeQuest derive_clock_uncertainty command, which creates set_clock_uncertainty values automatically. The derive_clock_uncertainty command is for other uncertainty sources like PLL jitter and static phase error; it does not account for the clock-skew-versus-data-delay uncertainty for ripple and gated clocks. (For the kinds of uncertainty that derive_clock_uncertainty does cover, this command is highly recommended for Stratix III, Cyclone III, and HardCopy II.) You will have to decide for yourself how much to allow for the additional uncertainty caused by ripple and gated clocks or whether to bother to account for it at all. Or just follow design guidelines #1 and #2 to avoid this issue altogether.