Who Said Clock Skew is Only Bad?

October 2, 2008

We always have this fear of adding clock skew. Well, seems like this is one of the holy cows of digital design, but sometimes clock skew can be advantageous.

Take a look at the example below. The capturing flop would normally violate setup requirements due to the deep logic cloud. By intentionally adding delay we could help make the clock arrive later and thus meet the setup condition. Nothing comes for free though, if we have another register just after the capturing one, the timing budget there will be cut.

This technique can also be implemented on the block level as well. Assume we have two blocks A and B. B’s signals, which are headed towards A, are generated by a deep logic cloud. On the other hand A’s signals, which arrive at B, are generated by a rather small logic cloud. Skewing the clock in the direction of A now, will give more timing budget for the B to A signals but will eat away the budget from A to B’s signals.

Inserting skew is very much disliked by physical implementation guys although a lot of the modern tools know how to handle it very nicely and even account for the clock re-convergence pessimism (more on this in another post). I have the feeling this dislike is more of a relic of the past, but as we push designs to be more complex, faster, less power hungry etc. we have to consider such techniques.


  1. Hi Nir,

    Useful skew is very much in favor of physical designer’s these days and without it, it is almost impossible to meet setup times in high performance designs.

    APR tools can automatically insert useful skew into the clock tree by deriving how much of it is needed to meet setup time on the data path. Once these margins are determined, they can be rolled into a bounded skew CTS (framework on which most CTS engines work with).

    Also sometimes these useful skew margins are used in a logic synthesis framework to overconstrain and optimize designs even further.

    This is no longer a serious issue if it is followed up with a proper OCV(on chip variation) based STA approach for signing off the chip.


  2. Nick,

    I can’t agree more with you. Actually this was the intention of the post in the first place.
    The assumption that the clock arrives *exactly* at the same time on every clock pin of every register in modern designs, is definitely not true.
    moreover, I think that big chips today look more like GALS (globally asynch, locally synch.) rather than fully synchronous…


  3. I would like to list the potential problems to have the complete picture in mind.

    1. If “CLK” delay has min/max. It will conside min dely for ‘setup’ and ‘max’ delay for ‘hold’ violations. If it has more ‘max’ delay then it can cause hold violation on the capturing edge.

    2. If there is a backward combo path f(rom B to A) available clock period will be less. So, there could be potential ‘setup’ violation.

    So, summary is
    a. A to B path improves Setup requiremnts and degrades hold requiremnts.
    b. B to A path degrades Setup requirements and improves hold requirements.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: