Honored ContributorThere 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?
Honored ContributorThe 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.Honored ContributorHi 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!Honored ContributorHi,
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.Honored ContributorCould you give me some suggestions about the output delay,I have been puzzling for a long time.
thank you very much!Honored Contributorpp. 19-22 of the timequest user guide (http://alterawiki.com/wiki/timequest_user_guide) give a good description.
Cheers, --slackerHonored ContributorHi 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!Honored ContributorIs there anyone can help me?
Honored ContributorThere 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...Honored Contributorli_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.
Honored Contributor
