Clock Skew doubt

Hi again,

I looked at slide 15&16. Obviously it is about the way classic tool (slide 15) and TimeQuest(slide 16) deal with regard to clock skew issue.

The demo assumes zero clock skew to begin with then injects skew of 2ns through PLL. Thus the PLL actually advances clock by 2 ns (but termed delay because actually PLL delays clk by 8 ns and clock edge wraps up as -2ns).

In both slides setup slack is calculated as:

slack=setup relatioship + clock skew - data delay.

Now let us look at original setup slack equations:

Clock Setup Slack = Data Required Time – Data Arrival Time

this is obvious.

then:

Data Required Time = Latch Edge + Clock Network Delay to Destination Register –micro tSU – Setup Uncertainty

Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +micro tCO + Register-to-Register Delay

if we now substitute:

slack = (Latch edge - launch edge) + (clk delay to dest-clk delay to sou)

+ - micro tSU -micro tCO - data delay [ignore uncertainty)

hence:

slack = setup relationship + clock skew -(micro tSU+micro tCO) - data delay

So here I want ask Altera!! what happened to -(micro tSU +micro tCO) term in above equations. Is it implied and computed internally when fmax is decided and hence set to zero? I don't believe so. It could be that the demo wants to be friendly while actual tool subtracts the above term.

Notice that with classic timing or timequest case, the whole idea of using clock offset or clock latency is a tool specific issue. At the end of the day the register have to latch at the physically occuring edge. It is matter of getting the tool right. Thus in slide 15 setup relationship is 2 ns while in slide 16 it is 12 ns. clock skew is zero in slide 15 but 2 ns in slide 16. Though we are talking about same one circuit. It is all a matter relative to tool maker's mentality.

Frankly, it is a mess to unlearn one tool and deal with a new tool. The designer's feel factor quality is never an issue in the market.