Hello, I have some problem understanding the set_input_delay min and max constraint. Assume that you have an interface that is connected to an FPGA. This interface has a clock (Clk) and a databus (DB). The datavalid window is centered around the rising edge of Clk. Assume a setup time of 1ns and a hold time of 2 ns. The clk period is 10 ns. How should I constrain this with the set_input_delay command? thanks for helping me,

1) Create a constraint on the clock coming in. Something like the following(I'm typing all constraints from memory, so syntax may be off): create_clock -name fpga_clk -period 10.0 [get_ports clk_in] 2) Create an external clock. (Users should always create a virtual external clock for I/O interfaces. This isn't emphasized enough in the documentation.) Since your clock coming in is phase-shifted, you can phase-shift it externally: create_clock -name ext_clk -period 10.0 -waveform {5.0 10.0} This basically phase-shifts the clock 180 degrees. Note that there are variations on this. You could have the external clock not be phase-shifted and phase-shift the fpga_clk. The analysis will end up being the same. 3) Add I/O constraints with 0.0ns delays, just as a place holder. set_input_delay -clock ext_clk -max 0.0 [get_ports din*] set_input_delay -clock ext_clk -min 0.0 [get_ports din*] 4) Undestand the setup and hold realtionship between ext_clk and fpga_clk. You can run TimeQuest and do a report_timing -setup and -hold between these two clocks. But just drawing the waveforms, it's pretty obvious the requirements are a 5ns setup time and a -5ns hold requirement. 5) Change the delay values to match your external delays. I don't follow your descriptions of "Assume a setup time of 1ns and hold time of 2ns". How much could the data come out before the clock, including board delays. If that's 4ns, then your -max delay should be 4ns and since the setup requirement is 5ns, TimeQuest is left trying to meet a 1ns setup time. If you're saying it could be delayed by as much as 1ns, then have that be the -max delay. For the hold, if the data may leave by as much as 2ns after the clock, the the -min delay is -2ns. Since the hold requirement is -5ns, then only if the dta is held by another -3ns will it fail timing. The language of setup and hold always seems confusing, especially the sign. Just start putting in numbers, rerunning TimeQuest and analyzing the setup and hold on the input paths. Look at the waveform to see if the analysis it is doing is what you want.

Ok many thanks Rysc for this useful explanation! Timequest documentation is not really easy to understand... Yet I have a question about this: 1) I do not understand why there is no relation between fpga_clk and the virtual ext_clk ? fpga_clk could not be created from ext_pll using create_generated_clock ?... (moreover there is a Quartus warning about this:" Warning: From ext_clk (Rise) to fpga_clk (Rise) (setup and hold) " 2)I don't know why "Report Fmax summary" is not available In Timequest report? It says "No paths to report", yet there is a path!

1) The assumption with generated_clocks is that there is a physical connection in the FPGA between the base clock and the generated clock, which TimeQuest then uses to calculate latency(delay). Note that clocks are related by default, so fpga_clk and ext_clk do have a relationship based on their edges. 2) I dislike Report Fmax and strongly recommend using slack as your measuring stick. Fmax works nicely when there is one clock domain and the transfers are all rising to rising, but can fall apart under more complex scenarios. Fmax calculations ignore transfers between different domains, because in many cases they don't work.

Hi, I am currently having an almost identical problem in a design. I hope its ok to add to this post and use it as a reference. I do not fully understand part of the first response by Rysc. --- Quote Start --- 5) Change the delay values to match your external delays. I don't follow your descriptions of "Assume a setup time of 1ns and hold time of 2ns". How much could the data come out before the clock, including board delays. If that's 4ns, then your -max delay should be 4ns and since the setup requirement is 5ns, TimeQuest is left trying to meet a 1ns setup time. If you're saying it could be delayed by as much as 1ns, then have that be the -max delay. For the hold, if the data may leave by as much as 2ns after the clock, the the -min delay is -2ns. Since the hold requirement is -5ns, then only if the dta is held by another -3ns will it fail timing. --- Quote End --- I understood before that the set_input_delay constraint was to account for board delays on the tracks? On my particular interface the rising edge of the clock and the data leaving the external device at the same moment. If in the example described by Rysc the max constraint is 4ns and the min is -2ns, basically Rysc is saying that the data could arrive to the FPGA ports 4ns after or 2ns before the clock. I do not understand what effect this constraint has. What is the advantage of telling this to Timequest? I don´t really have a clear understand of this constraint. Also in the previous example it is claimed that it is obvious that the setup time is 5ns and the hold time is -5ns. Again this is probably the dumbest question but can someone explain to me why that is the case. Fianlly after reading the timequest chapter in the Quartus handbook I do not understand the concept of virtual clocks. I would be very grateful if someone could explain to me in simpler terms why it is advisable to create one. I am a beginner to timequest and have been studying the documenation over the last few days. So far I am having trouble making sense of it. Hopefully if i can get a push in the right direction and get an understanding of the basics then it will start to come together. Many thanks for your help.

I'm not following the whole post. First off, don't spend forever reading the documentation. When you have a few constraints in, do something like the following, where you put in the portname you want to analyzer: report_timing -setup -from [get_ports your_portname*] -detail full_path -panel_name "Inputs setup" report_timing -hold -from [get_ports your_portname*] -detail full_path -panel_name "Inputs hold" At that point, look at the Data Path tab in excrutiating detail and figure out what it's calculating. Your clock relationship will be reflected in the launch and latch times, the external delays will just be a line item, and everything else should be either clock or data delay in the FPGA. Yours is a source synchronous output with clock and data edge aligned. Is it single-data rate or double-data rate? How are you shifting your clock to center it's edge on the data? (For single data rate you can just invert it at the capture register, or do a 180 degree phase shift in a PLL. If it's double-data rate, you'll want to use a PLL and phase-shift it 90 degree. Also, the PLL should be in source-synchronous mode.)

setup and hold time with set_input_delay | Altera Community

22 Replies

windy_city
New Member
1 hour ago
I could not locate your old documents. I have trouble with understand sset_input_delay constraint.
A) it is difference between data arrival and clock arrival time.
assume data and clock are coming from same external source. clock period is 10ns. set_input_delay is 3. external clock signal has trace delay of 4ns.
out of the 10ns, data used up 3ns, but clock also has a delay and reaches the internal flop late by 4ns, does it not mean that data now has 11ns to meet setup time of that internal flop?
how is it even possible that difference between their arrivals is 3ns but clock trace takes 4ns?
if clock trace takes 3ns, will data have 10ns internally to travel to the flop's input?
I will subtract setup time of the internal flop. I am trying to keep numbers simple.
B) if two chips are talking to each other then isnt set_input_deay of one chip same as set_output_delay of another chip. ? then why do I need both.
it will be big help if you can help me solve these. I asked AI and I was able to convince it to give me the answer I wanted.
Altera_Forum
Honored Contributor
14 years ago
Rysc, thank you kindly for your posts and clearing up IO constraints. The Quartus Documentation is extremely shotty. Thanks again.
Altera_Forum
Honored Contributor
16 years ago
Cyclone III's M9Ks have an output register that is bypassable. Not sure what error you're seeing, as it's definitely possible.
Altera_Forum
Honored Contributor
16 years ago
Thanks for the reply, It indeed allows to uncheck latches for the RAM, but i'm not sure weather it also allows for CYCLONE 3 FPGA.
It indicated some error when i did,and tried to compile.
Altera_Forum
Honored Contributor
16 years ago
In the Megawizard there is a checkbox to disable the output latch. (The input/address latch is always there).
Altera_Forum
Honored Contributor
16 years ago
hello Everyone,
Sorry for posting question in middle of no where, I did not find how to start new thread,Ok anyways
My question is,
The LPM Ram or Ram created thr MEGAWIZARD has a input latch and an output latch, because of which we are getting the 2 cycles delay in the output, which is very crucial in our design, how to over come the delay caused by the RAM, Cant we overcome this latch, if so how do we do it.
Altera_Forum
Honored Contributor
17 years ago
Thanks Rysc, placing derive_clock_uncertainty in the .sdc file seemed to sort it out
Altera_Forum
Honored Contributor
17 years ago
I think it just means to add the following line to your .sdc:
derive_clock_uncertainty
(That should be in all .sdc files for devices 65nms and newer...)

And note that, even though your slack is getting tight, if you meet timing, and if everything is correct, then you're in good shape. I've seen designs meet timing by a few picoseconds.
Altera_Forum
Honored Contributor
17 years ago
Thanks again Rysc for your reply.
I am fairly sure that the delay of 6.6 ns specified is the max delay between the rising edge of clock leaving the PowerPC and the time the data bits are stable. I have attached the datasheet and on page 78 these details are given. Perhaps you could have a quick look at this if you had time. On page 69 there is a timing diagram where the tov max delay term is used and it seems to refer to what I think.

Anyway I took your advice and used a PLL to shift the clock and I have been able to meet timing. I had to shift the clock by +5ns to meet timing. I now have a worst case setup time of 0.790ns and a worst case hold time slack of 2.123ns.

I have not included board trace delays in the input_delay constraints, its something I will add later, but I am assuming that they would typically quite low in the order of 100´s of ps?

I am also receiving some warnings about no clock uncertainty assignment on the clocks. From looking at the attached datasheet on page 67 it specifies the max and min high and low time for PerClk (the clock in question). The values given are that the clock can be high for between 7.5 and 9.9ns (50-66%)of a 15 ns cycle and low for between 4.95ns and 7.5 ns (33-50%) on a 15 ns cycle.
Does the potential difference in duty cycle represent clock uncertainty or am I misunderstanding clock uncertainty?
If my understanding is correct, then between the 6.6ns delay on the databus and the difference in potential duty cycle, it would make meeting timing even more difficult.

Do you have any thoughts on this?
Many Thanks
Altera_Forum
Honored Contributor
17 years ago
First off, make sure the spec is what you're saying. Outputs are often spec'd in terms of the input clock, i.e. the data is valid between 0 and 6.6ns after the input clock. This, by itself, is useless, since we want to know what the data output is in relation to the clock output. So if the clock output, in relation to the clock input, was 0 to 6.6ns, then we could figure out the skew between these.
Or is the spec saying the data comes out anywhere between 0ns(with the clock) up to 6.6ns after the clock? I don't know the answer, but it naturally makes a big difference. And skewed by anywhere between 0 and 6.6ns is a pretty big number(but not impossible).
Now, your setup requirement is 7.5ns. So that only leaves 0.9ns of skew inside the FPGA. First, if using a PLL in source synchronous mode, it's possible that you can meet that. Secondly, don't forget that you have -7.5ns of hold to work with. So if you're just barely meeting setup timing and have tons of hold timing, then Quartus might be able to reduce the data delay to borrow some of that hold timing. Or, you can add a positive phase shift of a few nanoseconds to your capture clock. (And you would add a multicycle -setup of 2 between the external clock and the PLL clock to get the correct requirement).

Bottom line is you still might meet timing, so give it a try. I do not think you need to go to a slower data rate.

Forum Discussion

setup and hold time with set_input_delay

22 Replies

Recent Discussions

setup and hold time with set_input_delay

Quartus 26.1 type inheritance bug.

Typedef inheritance in nested modules

Possible Quartus 24.1 bug?

TimeQuest User Guide