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