Clock Skew doubt

Hi AA,

Much of your thoughts are correct.

I will first put my overview in a nutshell. Later we can proceed further or discuss conflicts.

timing violations concepts

Whether your tool is classic timing tool or TimeQuest, the principles are naturally the same. The only difference is that TimeQuest added features applicable to very high speed issues.

classic requirement:

tSU/tH requirement i.e. data should be stable at the timing window at D input of a clocked register.

There is conceptually no difference at all between tSU and tH except for their relation to register clock edge. However, due to this very opposite orientation, they seem like two separate parameters.

high speed requirements:

Even if you satisfy classic requirement you may now (with high speed devices) bump into extra restrictions. Among them is minimum pulse requirement, minimum period requirement and tH restriction (here as an extra restriction relative to classic, needs further explanation)

related concepts:

Apart from above, some other concepts (not necessarily requirements per se) pop up regularly e.g tCO, bus skew, clock skew timing error, sampling error??

tCO is just a parameter representing time from clock edge to Q output stabilising. It is obviously not a requirement but is an important parameter considered when managing tSU/tH requirement at latch edge.

Bus skew is a natural event. When we view a bus of multiple bits then it is unlikely that all bits will change together. Each bit will have its own register somewhere. As such it may not matter but eventually the sample value will lead to error even though timing may be met per bit e.g. if read as address to memory.

Clock delay is also natural. Clock skew is used to mean difference of clock delays relative to registers. But in timing analysis, it is also loosely used to mean clock delayed more than data to a given register.

Sampling error is rarely used in the context of timing. It is used by receiver designers to indicate an ADC sampling point hitting the wrong time (e.g. missing peaks). But I find it useful in FPGAs as well especially across clock domains when I believe sampling error is more to blame than actual tSU/tH violation.

rtl chain:

An RTL chain of registers is the backbone of FPGA design. Logic work is handed from one stage to another with care at each edge.

From timing perspective, this chain is “broken open” at first registers and last registers. If the amount of logic cloud between a pair is too much it may be necessary to dilute it. At the extreme there might be zero cloud there.

The RTL chain provides a neat framework to control timing requirements. If one pair is controlled then all chain may be controlled.

Internally, the launch member of a pair provides information about the Q transition which is data to latch member. If such information is not available then it is impossible to control timing. For example, a tool will not report on first registers unless you provide information on external register (and board) that will join the chain. Similarly, the tool will not report as what will happen at external latch register unless you provide the required information.

timing window shift:

By far, this is the most important issue.

At the mouth of a register, the requiremet of tSU/tH is intrinsic, tSU is always +ve and in front of clock edge, tH is always +ve and behind clock edge. As such it is termed micro tSU/tH or reg tSU/tH.

But viewed at preceding point (launch register or input pins) then this window may slide dramatically across clock edge. This matters to the designers more than micro position because they deal with pins and not the internal micro (external devices also provide tSU/tH at the pins and not internal registers). The tool deals with the internal micro.

The formula for the sliding window in source synchrounous systems is this:

tSU (at pin) = reg tSU + (data delay – clk delay)

tH (at pin) = reg tH – (data delay - clk delay)

The same equations apply internally to any launching register perspective of next latching register tSU/tH .

The delays of clock/data could make either tSU/tH zero or negative and may result in their visual lengthening/overlapping if the sampling window slides past the clock edge. However, the actual length of sampling window stays constant as it is the sum of signed tSU + signed tH.