Clock Skew doubt

Hi Alteraaditya,

Regarding the question I raised in post 13 about slack equations in slide 15/16. After "years" of thinking I came to the conclusion that it missed tSU/tCO/tH because the presenter wanted to talk about "slack" rather specifically "setup slack" or "hold slack". The term "slack" as such is non official and it assumes zero requirements for demo only i.e. slack relative to clock edge itself. This is practically useless as slack must be related to edge of timing window.

A further practical issue:

When designing submodules, a common practice is to register the submodule outputs but not its inputs since inputs will acquire registers of front module at integration. When checking timing on the submodule as such then TimeQuest defaults to assuming that input/output ports are IOs but they are not and it cannot report on first set of registers because it does not have info on input signals. Similarly it cannot report on recovery/removal of reset which could be widespread in the submodule unless reset is passed first to a register but this is not the practice at submodule level.

Thus the timing report at submodule level is incomplete. One way to overcome that is add registers to all inputs and to reset temporarily for TimeQuest analysis only then remove them at integration as they will acquire registers at integration. The IO optimisation need also be set to off.

Alternatively some prefer set_false path to all IOs but I am not sure how accurate this is.

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.

Hello Kaz,

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?

How are "Setup Slack" and the "Setup relationship [the one Altera defines as the time between two consecutive latch and launch edge] related?

Thanks,

AA

Here is my table summary of io timing settings:

Inputs methods                            outputs methods                         
 
(1) tCO of ext device output         (1) tSU/tH of ext device input       (system centric)                 
(2) tSU/tH of fpga input               (2) tCO of fpga output?                  (fpga centric)
(3) skew at fpga input                  (3) skew at fpga output                 (skew at fpga)
---------------------------------------------------------------------------------------------------------
 
Commands and equations:
 
(1) input
Set_input_delay –max  < max tCO of input device + max data delay – min clk delay >
Set_input_delay –min   < min tCO of input device  + min data delay – max clk delay >
 
(2) input
Set_input_delay –max  < UI – tSU >
Set_input_delay –min   < tH >
 
(3) input
Set_input_delay –max  < +skew >
Set_input_delay –min   < -skew >
 
(1) output
Set_output_delay -max < tSU + max data delay – min clk delay >
Set_output_delay –min < - tH + min data delay  – max clk delay >
 
(2) output (possibly missing from TimeQuest doc)
 
(3) output
Set_output_delay -max < latch -launch – skew >
Set_output_delay –min  < latch –launch + skew >

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

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.