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

25 Replies

Altera_Forum
Honored Contributor
15 years ago
Rysc, thank you kindly for your posts and clearing up IO constraints. The Quartus Documentation is extremely shotty. Thanks again.
windy_city
New Contributor
1 month 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.
- KennyT_altera
  Super Contributor
  1 month ago
  Since there are no further queries, we shall close the case.
sstrell
Super Contributor
1 month ago
It would be a really good idea to start a new thread instead of resurrecting one that is 17 years old!
For A, you are describing a source synchronous interface ("data and clock are coming from same external source") so trace delay should match between clock and data, which usually cancels them out when calculating the value for set_input_delay. So either this statement is not correct (it's not a source synchronous design) or it is SS and very poorly routed on the board. Can you clarify the setup and where you are getting your numbers, including Tco of the external upstream device or any provide Tsu and Th requirements?
For B, are you talking about two FPGAs sending and receiving data? And again, is this meant to be SS or just synchronous with a common external clock source?
KennyT_altera
Super Contributor
1 month ago
sstrell is correct that the first thing is to distinguish source synchronous vs system synchronous.

For set_input_delay, the key point is that it describes the external data arrival window at the FPGA input pin, relative to the reference clock edge. It is not “remaining internal time after subtracting board clock delay.”

For a true source-synchronous interface, common clock/data PCB delay usually cancels, so what matters is mostly:

upstream device Tco(min/max)

clock/data board skew

jitter/uncertainty

A common model is:

set_input_delay -max = Tco_max + data_trace - clock_trace

set_input_delay -min = Tco_min + data_trace - clock_trace

refer to https://docs.altera.com/v/u/docs/653688/an-433-constraining-and-analyzing-source-synchronous-interfaces

So if data and clock traces are matched, the trace delay does not magically give the FPGA extra internal time.

Also, set_output_delay on the transmitting chip and set_input_delay on the receiving chip are related, but they are not redundant. One constrains the transmitter against receiver requirements; the other constrains the receiver against transmitter behavior.

Forum Discussion

setup and hold time with set_input_delay

25 Replies

Recent Discussions

Synthesis error

ModelSim Intel FPGA Ed. 2020.1 not updating changes to HDL File

System Console master_read_memory fails above 7688 bytes on Agilex 5 (AXE5-Eagle)

Quarus Prime Installer 24.1 - Error SSL Certificate, Curlcde : 60

Problema Usb_Blaster con Windows 11