Clock Skew doubt

--- 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

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.

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

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.

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

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 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.

--- 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.

Hi AA,

I am going to work tomorrow and may not be free to post. So I will add some info about io timing to complete the RTL chain:

How does io timing come into the scene?

The fpga input registers are at the mercy of the outputs from the external input device signals. Similarly, the input registers of the external output device are at mercy of fpga output signals. These two sets of nodes are no less important than fpga internal RTL chain. Here, designers are on their own to get it right by reporting correct figures to the tool.

At the very start, you need to allocate responsibility of io timing closure; is it the fpga responsibility or the external devices or shared?

Let us first assume that fpga is responsible for both ends.

For fpga input register timing, the designer must know the input data relationship to its clock (tCO of external device as well as board delays). In essence they need to know data/clock relationship at input pins of fpga. If such information is not available then the timing tool is unable to report on the paths to these registers (and does not give warnings).

For the external device input register timing, the designer needs to get information about their requirements and board delays. Many devices have tSU/tH requirements (figures apply to their pins rather than internal registers). Some modern devices do not have these requirements because they have opted for automating clock tracking features but then they still require minimum skew of the received data bus.

If the fpga input registers timing is not the responsibility of fpga then the external input device needs to know fpga tSU/tH at pins and board delays. Similarly if the external output device takes over responsibility then it needs to know tCO of fpga and board delays or perhaps just the fpga data skew range.

To my understanding, the above discussion is the basis of TimeQuest system-centric Versus fpga-centric methods. System centric implies fpga is responsible for the system. Fpga centric implies external device is responsible (not fpga).

Thus fpga centric approach reports the tSU/tH of fpga input pins just like say a DAC chip does. And it reports on FPGA output pins tCO just like an ADC chip does. It does not take responsibility of system timing.

Therefore, it is no surprise that these two methods give different results and they are not alternatives that you can simply choose whichever at will.

edit: having said that, the fpga centric approach can be adapted to meet external device requirement i.e. knowing the external device information you may opt to calculate best tSU/tH or tCO to match instead of system centric approach.

Hello Kaz,

Thank you, I am reading manuals and watching some videos. Your posts are clarifying my thought process to some extent.

Thanks again,

AA