Clock Skew doubt

Hi,

--- Quote Start ---

Lets say the setup relationship is 10ns. This means the data from the launch edge has (10ns - microTsu) for it to reach register b in order for the data to be latched successfully. Is this right?

--- Quote End ---

In the context of io you better drop the concept of micro as setup is referred to ext device pins. In your case, the maximum offset of data from launch clock must not exceed 10-tSU (assuming no data,clk board delay differences) i.e. max = tSU from latch edge and that is what set_output delay means.

The relation between setup slack and setup relationship is detailed in post 13 above.

Further notes on io issues:

Note1: delay figures

whatever your chosen delay figures mean, the tool does not know how you got them, it only sees these figures of course.

Note2: input delays

Input delay based on tCO of external device: You are telling TimeQuest that data is offset from launching clock edge at fpga pins by min ~ max delay. i.e. TimeQuest to expect a skew of (max-min) and deal with it.

Input delay based on tSU/tH of fpga: You are telling TimeQuest to make FPGA pins appear with those values of tSU/tH. It is then up to you to choose correct figures to match the external device’s tCO. This was the method used with classic timing analyser.

Input delay based on skew only: You are telling TimeQuest to expect a skew of (max-min) around clock edge.

Note3: output delays

Output delay based on tSU/tH of external device: you are telling TimeQuest to produce data offset of max and min with respect to latch clock edge (infront of it), with tSU entered as positive and tH as negative. TimeQuest will produce a skew of (max –min) centred on that offset.

Output delay based on skew: targets skew and not data delay. It does not care about external device’s tSU/tH and will violate it unless by sheer luck.

Early/late edge method of output (fpga centric) ??? possibly related to Output tCO method ??? I am not clear about this.

In all cases, instead of entering actual max/min values I prefer to target minimum skew with my delays i.e get optimum point centred between max/min then enter max = min = centre point between them relative to correct clock edge. In other words you are targeting the ideal case of setup slack equal hold slack. You can relax the difference of max,min over zero if in difficulty.

A pass or fail reporting depends on your entries so be careful.

So far no major problem of understanding,the dirty stuff then comes when timing exceptions are applied depending on clock relations, any of above delay equation are true for the default case of launch/latch which is defined in documents. If your case is not the default then you need to do some more work. is I will try have a go at it later.