skew for common clock path

[chevuturi]

do we have skew for common clock path ? if no why ? if yes how do we calculate ?

 

[D.A.(Tony)Stewart]

CCP is not affected by variations in fanout cap or driving strength or input threshold. There is another thread where this topic is being discussed and I mention crosstalk there. Crosstalk does matter because it is not constant from one edge to the next.

Yes, yada yada, all digital circuits are analog, but they are analyzed as digital circuits by the digital CTS tools that handle CPPR.

No retraction or rebuttal?

 

[D.A.(Tony)Stewart]

Hi Tony. You seem to have very limited knowledge of CPPR, throwing random terms from PCB design and whatever else you could find on VLSI websites about CTS and how STA works in a clock tree. This is *not* what OP is asking, you are muddying the water. On top of that, you have this continuous thing about a job at AMD?! I really don't get it but I will leave at that and put you on my ignore list moving forward. On other topics you seemed to have spewed even higher BS level with AI generated answers that are not exactly what I would call good.

For other forum users, please refer to kaz1 answer. You want deep insights into CPPR, Innovus documentation has a great chapter on it. Also worth reading is the (A)OCV derating behavior as it is intimately linked to CPPR. This is all you need to know.

Your opinions are false and your comments are inflammatory and unprofessional.

"skew as in clock skew from clock tree implementation: no. "
May be generally true for simple design but is patently false as a rule as I proved with examples. You seem to know little about the real world in CTS at 6 GHz speeds.

"CCP is not affected by variations in fanout cap or driving strength or input threshold. "


This is pure BS and then you deflect it to a crosstalk jitter discussion which can be relevant but fallacious negation of my truth.
Facts. The capture time varies with data voltage threshold and risetime therefore both skew and Common Clock Skew after corrections are both affected.
Capture time is the metric that determines skew after launch.

Your argumentums are fallacious.

BTW I was doing clock tree analysis before EDA tools existed and before you were born. I don't need any experience in Cadence tools to understand.
e.g. 68000 dual-port bit-slice 32 bit micro's with dual-port SCSI. with manual CTS
I designed a discrete UART before Motorola released the first IC and mine was fully functional. -40 to 70'C in the 70's. with high margins.

Please do avoid personal attacks. They don't look good on any professional. AMD reference was intended to be a joke with a bit of a jab.
Those who have done as I have can speak from experience not just cite theory.(with flaws)

 

[fametomex]

skew as in clock skew from clock tree implementation: no.

 

[mkostya]

Common clock path can have different delays in different clock periods, mainly because of variation or crosstalk, therefore common clock path can have skew.

 

[kaz1]

Common clock path can have different delays in different clock periods, mainly because of variation or crosstalk, therefore common clock path can have skew.

common clock path is a single wire. Every single wire is one wire... any wire delay is never constant and the static timing tool checks the range of variation.

 

[mkostya]

common clock path is a single wire. Every single wire is one wire... any wire delay is never constant and the static timing tool checks the range of variation.

It’s not a single wire. It’s a path which consists of gates and interconnects. The delay of such a path can change in time. For example, if there is a neighbor net that switches at one direction at time X
and the same net switches in opposite direction at time X+T, then the same physical clock path might have different delay as a result of different cross coupling capacitance. Call it skew or not - but in reality the same common clock path will have different delays in consecutive clock periods and you will have to take this difference into account when calculating slack at the sampling FF input.