How to determine the maximum and minimum of input delay?

[Altera_Forum]

There are a lot of delay datas about the ports in the SDC file that are used to constrain the desgin.but I don't know how to determine the maximum and minimum of input. 

Is there anyone can give me some suggestion?

[Altera_Forum]

The short answer first: 

 given tCO of external input device then (ignoring board delays) set delays as follows: set_input_delay -max tCO ... set_input_delay -min tCO ...  if you want to include board delays and I bet that is horribly difficult but you can make estimate using length of trace, speed of light, capacitance ... then change tCO to : tCO +data delay(max) - clk delay(min) for -max change tCO to : tCO +data delay(min) - clk delay(max) for -min  Now the long story: My personal verdict on TimeQuest(TQ) package of documentation is that it is the worst ever that I have seen.   I don't care if pins are called ports or ports are called pins, the trouble is they have done their best to confuse and wipe off common sense.  According to my struggle I see Timequest allows three ways to determine input delays. 1) given tCO of external input device 2) given tSU/tH of external device. 3) given skew   The crux of the matter is that Timequest needs to know the clock data relationship. Thats all. From that it inserts delays to move timing window to a location at pins so that internal registers timing window is optimum.  The relation of these delays to timing window shift is common sense:  tSU(at pin) = data delay - clk delay + tSU(at register) tH(at pin) = clk delay - data delay + tH(at register)  The full timing window at pins is tSU(at pins) + tH(at pins)  Thus to get optimum window at pins, TQ needs to know the three variables in above equation. The register tSU/tH are related to device type ...etc. the delays are inserted by fitter so it knows their values.  To make life easy !!! for us, TQ lets you enter tCO of external device and it works out the timing window at pins.  The main problem to me is the meaning of "delay". Does it mean above delays in the equations. I doubt it.  As an example of confusion of meaning of delay, you have the option to use one of two sets of commands:  set_input_delay -min (called system centric) as in the short reply above set_min_delay (called fpga centric)  The strange thing is that the meaning of delay flips over and does not seem to mean the above delays in the equations or anything consistent as the two statements below are equivalent ????:  set_input_delay -min <tH> --i.e. positive tH set_min_delay <-tH> --i.e. negative tH  Now let us pretend we understood tCO case (1)  What about number (2): How do we relate tSU/tH of external device to data/clk relation. A complete mystery to me.  The case of skew (3) is not difficult to understand but I haven't yet seen a device giving skew instead of tCO.

[Altera_Forum]

Hi kaz! 

Thank you so much for your suggestion about the input delay.but there is something that I still can't understand. You show me the "tsu(at pin) = data delay - clk delay + tsu(at register) th(at pin) = clk delay - data delay + th(at register)" but I think the tsu and th are determined by the devices rather than the data delay ,tsu and clk delay.   The output delay is also confused to me,according to my projections I think the Output Minimum Delay and Output maximum Delay should be "output minimum delay = th - <max data delay> + <min clock delay> output maximum delay=t(period)+<max clock delay>-<min data delay>-tsu",but the truth is not so.Some data shows that "output delay max= (tdata_pcb(max) + tcl) - (tclk2(min) - tclk1ext(max) ) + tsu output delay min= (tdata_pcb(min) + tcl) - (tclk2(max) – tclk1ext(min) ) - th".it's indigestible!  thank you very much!

[Altera_Forum]

Hi, 

 I already mentioned that register tSU/tH is inherent to device(also called micro tSU/tH. When viewed from device pins, the timing window shifts as explained in the equations. It is these delays that are the backbone of getting timing right. i.e. the fpga has configurable tSU/tH unlike ASICs which usually have fixed tSU/tH in their spec. In all cases we refer to pins because that is what is relevant to the designer.  Regarding output delays, We are talking about input delays. That is a different story and depends on tSU/tH of external device.

[Altera_Forum]

Could you give me some suggestions about the output delay,I have been puzzling for a long time. 

thank you very much!

[Altera_Forum]

pp. 19-22 of the timequest user guide (http://alterawiki.com/wiki/timequest_user_guide) give a good description. 

 Cheers,  --slacker

[Altera_Forum]

Hi slacker! 

The timequest user guide (http://alterawiki.com/wiki/timequest_user_guide) is so great,thank you very much! The output delay and input delay are so puzzling,the output delay waveform shows that the ext_clk move forward 4ns but the out put delay shows 4ns and the ext_clk delay 1ns the out put delay shows -1ns,its't unbelievable.But the input delay waveform is significantly different from output delay. thank you!

[Altera_Forum]

Is there anyone can help me?

[Altera_Forum]

There are some nuances that not all pieces of documentation cover but I thought this guide offered a good perspective... http://www.altera.com/literature/an/an433.pdf  

 Ofcourse I can never say with confidence that I understand anything that Altera offers due to their scattered nature of documentation... blame it on documentation or the complicated devices themselves...

[Altera_Forum]

li_polaris, can you explain your question on thumbnails showing input and output delay? Looking at the output delay, the clocks don't move at all. They are 10ns and "ideal". The set_output_delay -max 4.0 states that the external max delay is 4ns. On a simple level, that means the FPGA needs to get it's data out within 6ns so that, after the external 4ns delay is added, it can be captured by the latch edge at time 10ns. Now, where does that 4ns come from? Generally it is the data's board delay + Tsu of the external device. For example, if the board delay was 500ps, and the Tsu was 3.5ns. (A Tsu of 3.5ns says the data needs to be present 3.5ns before the clock, which is identical to saying there is a 3.5ns delay on the data path inside the external device, compared to the clock path in the external device). Now, that hasn't accounted for any board level clock skew between the FPGA and the external device. The guide should go into that later on in that section, but let me know if it's not clear. Any suggestions you have for improvement or something that's not clear would be welcome.

[Altera_Forum]

--- Quote Start ---  The short answer first:  given tCO of external input device then (ignoring board delays) set delays as follows: set_input_delay -max tCO ... set_input_delay -min tCO ...  if you want to include board delays and I bet that is horribly difficult but you can make estimate using length of trace, speed of light, capacitance ... then change tCO to : tCO +data delay(max) - clk delay(min) for -max change tCO to : tCO +data delay(min) - clk delay(max) for -min  Now the long story: My personal verdict on TimeQuest(TQ) package of documentation is that it is the worst ever that I have seen.   I don't care if pins are called ports or ports are called pins, the trouble is they have done their best to confuse and wipe off common sense.  According to my struggle I see Timequest allows three ways to determine input delays. 1) given tCO of external input device 2) given tSU/tH of external device. 3) given skew   The crux of the matter is that Timequest needs to know the clock data relationship. Thats all. From that it inserts delays to move timing window to a location at pins so that internal registers timing window is optimum.  The relation of these delays to timing window shift is common sense:  tSU(at pin) = data delay - clk delay + tSU(at register) tH(at pin) = clk delay - data delay + tH(at register)  The full timing window at pins is tSU(at pins) + tH(at pins)  Thus to get optimum window at pins, TQ needs to know the three variables in above equation. The register tSU/tH are related to device type ...etc. the delays are inserted by fitter so it knows their values.  To make life easy !!! for us, TQ lets you enter tCO of external device and it works out the timing window at pins.  The main problem to me is the meaning of "delay". Does it mean above delays in the equations. I doubt it.  As an example of confusion of meaning of delay, you have the option to use one of two sets of commands:  set_input_delay -min (called system centric) as in the short reply above set_min_delay (called fpga centric)  The strange thing is that the meaning of delay flips over and does not seem to mean the above delays in the equations or anything consistent as the two statements below are equivalent ????:  set_input_delay -min <tH> --i.e. positive tH set_min_delay <-tH> --i.e. negative tH  Now let us pretend we understood tCO case (1)  What about number (2): How do we relate tSU/tH of external device to data/clk relation. A complete mystery to me.  The case of skew (3) is not difficult to understand but I haven't yet seen a device giving skew instead of tCO.  --- Quote End ---    hi,kaz."number (2): How do we relate tSU/tH of external device to data/clk relation. A complete mystery to me." I'm confused too. This question , for you, almost 3 years pass,I think you must have understood it. Could you show me how to relate tSU/tH of external device to data/clk relation? according to the altera document"AN433:Constraining and Analyzing Source-Synchronous Interfaces" set_input_delay -max UI-tSU_ext set_output_delay -min tH_ext it's difficult to understand for me. Instead &#65292;the case(1) you mentioned using tCO to set_input_delay is much easier &#12290;Then the question can also change to find out the relationship of tCO and tSU/tH of external device's output port .In my opinion, for the output port of external device ,tSU/tH means the output data will be stable during the {tSU,tH} window,right? So, after the launch clock edge,the data must be transport to the output port before tH of the external device,otherwise the data will be unstable.So, we get tCO_max=tH. for the similar situation,tCO_min = -tSU. then,we should get: set_input_delay -max tH_ext set_output_delay -min -tSU_ext what do you think?  thanks. Andrew

[Altera_Forum]

--- Quote Start ---  hi,kaz."number (2): How do we relate tSU/tH of external device to data/clk relation. A complete mystery to me." I'm confused too. This question , for you, almost 3 years pass,I think you must have understood it. Could you show me how to relate tSU/tH of external device to data/clk relation? according to the altera document"AN433:Constraining and Analyzing Source-Synchronous Interfaces" set_input_delay -max UI-tSU_ext set_output_delay -min tH_ext it's difficult to understand for me. Instead &#65292;the case(1) you mentioned using tCO to set_input_delay is much easier &#12290;Then the question can also change to find out the relationship of tCO and tSU/tH of external device's output port .In my opinion, for the output port of external device ,tSU/tH means the output data will be stable during the {tSU,tH} window,right? So, after the launch clock edge,the data must be transport to the output port before tH of the external device,otherwise the data will be unstable.So, we get tCO_max=tH. for the similar situation,tCO_min = -tSU. then,we should get: set_input_delay -max tH_ext set_output_delay -min -tSU_ext what do you think?  thanks. Andrew  --- Quote End ---    Yes I think I understood case(2) after 3 years!  The problem was that they don't tell tSU,tH of which device. I now assume that they mean those given by external device datasheet as requirement on receiving device . i.e. some devices give them instead of tCO(which makes more sense). In other words the manufacturer tells you that they require fpga tSU/tH to be those values. hence the equations become:  -max UI-tSU -min tH  This is basic if you draw clock waveforms and remember that tSU relates to current latching edge while tH relates to previous latching edge.  Edit: However, admittedly I don't see how external device tCO = UI-tSU(of fpga) if manufacturer does not know about UI i.e. clock speed used.