Clock skew? Good or bad?

Question

So, I've been reading up on clock skew. I came across the fact that clock skew can be incredibly useful, in the sense that positive skew can be used to speed up the circuit by increasing the clock's frequency.
Then why are there so many measures taken to completely eliminate clock skew? It seems to me that having a controlled amount is extremely beneficial? Are there any harmful effects of clock skew?

Clock skew does not itself speed up the clock frequency. However, if clock skew insures that the data is arriving before it is needed, it may mean that the system could safely run at a higher clock frequency. Conversely, if the sum of skew + delay means the data is arriving later than needed, it means that either the clock frequency or the skew must be reduced. — Chris Stratton, Nov 11 '12 at 17:30
http://eda360insider.wordpress.com/2011/07/12/clock-optimization-the-primer-to-the-primer%E2%80%94or%E2%80%94want-to-overcome-some-major-functional-hurdles-to-silicon-realization-and-save-a-lot-of-power-on-your-soc-at-the-same-time/ is a worthwhile read (I worked on the technology it's describing; there is a better paper linked from there that you have to register for) — pjc50, Nov 12 '12 at 09:44
See also: http://electronics.stackexchange.com/questions/39712/what-is-clock-skew-and-why-can-it-be-negative/39726#39726 — embedded.kyle, Nov 12 '12 at 16:45

score 3 · Answer 1 · answered Nov 11 '12 at 16:59

Clock skew happens when clock edges happen at different times in different blocks of the circuit. This may be due to physical distance, clock buffers or parasitic reactances. Skew can be positive or negative (clock anticipated or delayed), depending on which signal is taken as reference.

Normally, in a synchronous network clock skew can generate errors in the data: an example are dynamic gates, where the output is pre-charged in a phase of the clock and elaborated in the other. Skew may cause the propagation of the pre-charge state instead of the right one.

In synchronous logic, skew is considered together with latency, setup time and hold time of gates and registers to determine the maximum clock frequency that can be used. If skew is not known a priori, it must be considered as a tolerance and will contribute negatively to the speed of the system.

Skew can also be used to delay the clock to a register, providing more time for the logic before that register to elaborate. Therefore a faster clock can be used still satisfying the requirements of setup and hold time of the register.

This is a brief explanation and may not be clear, but you can always google or check on wiki for more details.

score 1 · Answer 2 · answered Apr 23 '15 at 07:47

You got it wrong that clock skew can be incredibly useful. Yes, setting the right skew may help you to increase the clock rate sometimes, but the effect is rather limited.

On the other hand, having a core which requires clock skew to work has many downsides. You can't synthesize it for FPGAs / ASICs which don't have an extra PLL just to generate the right skew for you. Changing the FPGA family alone will probably require you to reestimate the amount of skew required. Modifying such core created by someone else is a nightmare.

The only case I would touch to skew settings is when I have a complete design for a specific chip and I can't get the required clock rate by other means.

Think of software optimization as illustration: you can go faster by rewriting your function in assembly, but it has to be the right function (the one in the hot loop), and you lose on portability, maintainability and code reuse. Premature optimization is on the top list of errors inexperienced programmers do.

score 0 · Answer 3 · answered Dec 09 '13 at 21:18

In many digital logic systems, there will be combinations of events (call them X and Y) which must not occur simultaneously. The system will behave in a defined fashion if X happens before Y, and will behave in a (typically different) defined function if Y happens before X, but its behavior will will be undefined if they occur simultaneously (since most events of interest take a small but non-zero amount of time; events are considered simultaneous if any portion overlaps).

If events X and Y are triggered by the clock-generator pulse, it will often be necessary to ensure that the time between that pulse and X is either definitively longer than the time between that pulse and Y, or else definitively shorter. Clock skew in a system will generally have the effect of changing the amount of time between the moment the clock generator starts to outputs a pulse and the times when different events occur. Clock skew which would push events closer together in time is bad, and may result in malfunction if the times end up overlapping. Clock skew which would increase the separation between events which are supposed to be separate is generally good, provided it doesn't decrease by too much the separation between other events which also need to be separate.

Many systems have a variety of interrelated timing constraints; while it might be possible to improve timing margins if one had sufficiently-precise control of timing skew, it would often in practice, given the level of control which is easily available, be difficult to improve some critical timing margins by adding timing skew without making other equally-critical timing margins worse. It's generally easier from an engineering perspective to try to minimize skew than it would be to "optimize" it, so that's what implementations generally do.

Clock skew? Good or bad?

3 Answers3