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

Altera_Forum
Honored Contributor
17 years ago
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!
Altera_Forum
Honored Contributor
17 years ago
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.

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