Clock Skew doubt

--- Quote Start ---

Hello kaz,

Thanks for breaking up the equations in post# 13. I am still understand the slide 16. I guess its easier for me since I am learning Time Quest and haven't used older version.

Thanks,

AA

--- Quote End ---

I am still however puzzled why the slide 15 and 16 ignore the term tSU + tCO. They must come into scene otherwise the whole purpose of timing is defeated. The equations after all are from altera and they make sense. So how is that a substantial and most important term is ignored by the slide presenter. I hope the actual tool is different.

It could be the presenter wanted an easy equation for demo only. I hope somebody can answer that.

--- Quote Start ---

always @(posedge clock_a) begin

reg_a <= temp;

end

always @(posedge clock_b) begin

reg_b <= reg_a;

end

What happens when I synthesize this? [say clock_a = 22.4Mhz and clock_b = 45.4Mh, assume these frequencies are available]. Will I always get wrong data from reg b?

c. I want to clarify, what should come to my mind when I hear the term "unrelated clock" and "related clock" ?. My understand was, "if two clocks are have different frequencies and if rising_edge_clock_a = n * [rising_edge_clock_b] for n= 1,2,3.. then clocks are related.

d. Does the term "related" and "unrelated" has to do something with the clocks derived from the pll. Eg. all the clocks derived from pll are related [irrespective of the fact that their rising edge may not coincide] with each other.

Thanks,

AA

--- Quote End ---

knowing just the frequency value is not enough. You need to know phase relationship otherwise I will treat the two clock domains as asynchronous.

by related clocks I mean there is a predefined phase relationship. In other words, the setup or hold relationship is predictable though may change from edge to edge but there will be worst case to be evaluated.

for example if 20MHz clock is to generate two clocks; 25MHz and 50MHz in phase then we know the edges will coincide every other clock of 50MHz. if it has to generate 25MHz and 30 MHz in phase(at the start) then you can draw the two clocks and find out worst case.

In all cases if in doubt you better assume they are asynchronous at some cost.

Moreover, the tool will tell you if it passes or not. If it doesn't then go for clock domain transfer as asynchronous.

Hello kaz,

Thanks for breaking up the equations in post# 13. I am still understand the slide 16. I guess its easier for me since I am learning Time Quest and haven't used older version.

Thanks,

AA

always @(posedge clock_a) begin

reg_a <= temp;

end

always @(posedge clock_b) begin

reg_b <= reg_a;

end

What happens when I synthesize this? [say clock_a = 22.4Mhz and clock_b = 45.4Mh, assume these frequencies are available]. Will I always get wrong data from reg b?

c. I want to clarify, what should come to my mind when I hear the term "unrelated clock" and "related clock" ?. My understand was, "if two clocks are have different frequencies and if rising_edge_clock_a = n * [rising_edge_clock_b] for n= 1,2,3.. then clocks are related.

d. Does the term "related" and "unrelated" has to do something with the clocks derived from the pll. Eg. all the clocks derived from pll are related [irrespective of the fact that their rising edge may not coincide] with each other.

Thanks,

AA

a. yes

b. no, you the designer inserts synchroniser directly or by using dc fifo...

c. yes and no. you should say unrelated clocks rather than Different clocks which may be related e.g. 20MHz and 40MHz may be related if say generated from one other clk and you can synchronise between them.

Opps sorry! Yes, I had mistakenly written Tsu instead of "setup relationship".After reading your reply in post 12 I understood more about timing and I answered my questions.

To my question, are these the right answers?

a. Yes, it is the right reason to cut it. Yes, the error just doesn't show up in the Analyzer, but the errors occurs in the hardware.

b. The Quartus automatically takes care of it by inserting synchronizes and FIFO.

c. Yes, it is the right thing to do.

Yet to read post# 13

Thanks,

AA

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.

--- Quote Start ---

case 1: clock_a is same as clock_b

Here the Time Quest Analyzer automatically considers the setup to by one cycle [lets say this is 10ns] and then tries to meet the timing requirement by positioning the position of register_b so that the setup time and hold time are not violated.

--- Quote End ---

If you are saying that clock cycle is 10 ns and hence setup is 10 ns then that is a big mistake. tSU is intrinsic to register and is totally unrelated to clock period.

May be you are mixing between the concept of tSU and setup relationship i.e. launch edge to next latch edge which is 10 ns. This is relationship and not actual tSU at all.

--- Quote Start ---

case 2: if they are different clocks

Here the Time Quest Analyzer considers the setup time for the path to be the time units between the two consecutive rising edges[ lets say this time between rising edge of clock_a and clock_b is 2ns]. So, in this case the setup time is considered as 2ns and the maximum delay the data can have before reaching the input of the destination register is 2ns. lets assume this cannot be met during which I can use:

1. set_false_path

2. set_clocks_group

3. set_multicycle [if the rising edges between the two clocks coincide]

my questions:

a) In the above para I described the reason why I would cut the analysis of the unrelated clock domain. Is it the right reason to cut it ? :) When I decide to cut the unrelated clock domains, is it just to get less timing errors in the Time Quest Analyzer[TQA] and reduce the stain on the fitter?

b) By using option 1 and 2, I am telling the TQA not to analyze that path. Though it is clocked by two different clocks, some one has to make sure that the rising edge of clock_b doesn't appear before/after the latching window at register_b. Who takes care of this?

c) If this is the right way to use set_false_path then, even before compilation I will set false path between all the clock domains that have a different frequencies. Is it the right thing to do?.

--- Quote End ---

If clocks are unrelated then you will get timing error, no matter what you do because the clock edges will come anytime.

The path becomes asynchronous. At such points in your design you need extra work to avoid consequences of inevitable timing error:

For the occasionally changing signal e.g. nios sending frequency value on its clock to an NCO on a different clock then a two stage synchroniser

will dampen metastability and prevent it propagating through.

for regularly changing signal e.g. data path then you need two stage synchroniser plus data transfer through handshake arrangement such as that done in dc fifo.

In both above scenarios (NCO,data) you need to cut path on the first register of the two stage synchroniser. This is not cheating the report but timing errors will occur on that register and you don't want the tool to tell you that.

Same applies to asynchronous reset release. (will discuss later)

The TimeQuest command (set false path) and (set clock groups) are targetting the same one issue of cutting paths. For single paths you can just use the first. For multiple clocks it is more convenient to use set clock groups.

For the flash presentation, I need to look at the presentation first in due time...

Regards

Kaz

Hello Kaz,

Here are some of my doubts;

-----------------Question 1--------------------

Lets say there are two registers [register_a and register_b]. Data goes from register_a to register_b. [in space register_a comes before register_b]. Let clock_a and clock_b be their respective clocks. Now the data is handled by two different clocks and therefore it is passing through different clock domains.

case 1: clock_a is same as clock_b

Here the Time Quest Analyzer automatically considers the setup to by one cycle [lets say this is 10ns] and then tries to meet the timing requirement by positioning the position of register_b so that the setup time and hold time are not violated.

case 2: if they are different clocks

Here the Time Quest Analyzer considers the setup time for the path to be the time units between the two consecutive rising edges[ lets say this time between rising edge of clock_a and clock_b is 2ns]. So, in this case the setup time is considered as 2ns and the maximum delay the data can have before reaching the input of the destination register is 2ns. lets assume this cannot be met during which I can use:

1. set_false_path

2. set_clocks_group

3. set_multicycle [if the rising edges between the two clocks coincide]

my questions:

a) In the above para I described the reason why I would cut the analysis of the unrelated clock domain. Is it the right reason to cut it ? :) When I decide to cut the unrelated clock domains, is it just to get less timing errors in the Time Quest Analyzer[TQA] and reduce the stain on the fitter?

b) By using option 1 and 2, I am telling the TQA not to analyze that path. Though it is clocked by two different clocks, some one has to make sure that the rising edge of clock_b doesn't appear before/after the latching window at register_b. Who takes care of this?

c) If this is the right way to use set_false_path then, even before compilation I will set false path between all the clock domains that have a different frequencies. Is it the right thing to do?.

-----------------Question 2--------------------

In the flash presentation "Switching to Time Quest Timing Analysis" [This is an Altera Legacy training] in slide 16:

a) Since Pll clock is delayed by 2ns shouldn't the 1st rising edge of "pll_clk" appear 2ns after 1st rising edge of "clock"? Its the other way around in the video!!

b) Why do they add +2 while calculating the slack?

Thanks,

AA

Hi AA,

Thanks for your words. I will now add part II so you may focus on further points:

Now, how does a timing tool control tSU/tH inside fpga (ignoring io registers i.e. first fpga register and last external register in chain):

Note: to visualise properly this discussion, you need to imagine two registers i.e. launch/latch registers as two successive nodes in space. At the same time you need to visualise two clock edges in time domain at each register that relate by finite delay.

1) tSU violation is avoided by restricting clock period to a minimum such that the data transition (tCO) of launch almost hits tSU of latch.

In other words:

Fmax = lowest of 1/[reg tCO + reg tSU + (data delay – clk delay)] across all launch/latch pairs.

This applies to [edge to next edge] setup relationship. i.e the setup relationship is between current launch edge and following latch edge. It may differ in various systems e.g. it could be with opposite edge relationship(rise-fall) or have multicycles.

2)tH violation is avoided in silicon fabrication stage by making sure clock is never delayed more than data (global lines being fast).

Except for very fast clocks, fmax has nothing to do with tH because fmax is based on data transition never hitting tSU window so how can it pass across clk edge and hit tH window, however, the tool will check tH with respect to current (not next) edge at latch register and normally tCO ensuers kicking data transition well away from tH window. Put in other words, the tH relationship is bwteen current launch edge with current latch edge.

Above discussion applies to classic tSU/tH requirement. With high speed requirements, the pulse/period duration (toggle rate) may obviously have their own restrictions. Moreover, tH violation may occur now despite silicon avoidance, i.e. if clock is very fast then data transition (decided by tCO) could be too close to current edge at latch register. When fmax is restricted due to these extras then it is termed simply “restricted fmax”.

Apart from the chain structure of launch/latch pairs, there are cases of feedback e.g. an accumulator where launch/latch is to the same one register. Here, the same rules apply as if they are a pair.

To improve fmax, one needs to add more registers(pipe) to breakup the cloud of logic in between a pair or in a feedback path. Alternatively, one can add more copies of same register if you want to avoid the pain of functionality balancing caused by extra pipe. In equation terms this helps reduce data delay factor.

To avoid tH violation, do not gate the clock. If it is localised then you may try delay the data involved.

For specific sections you may also consider clock phase rotation (using PLL) but this is more commonly done at io.