Question about set_input_delay and set_output_delay

Look at the TimeQuest User Guide on alterawiki.com about these constraints.

Yes, they do just tell the external delays(aka setup and hold, depending on how you look at it). But you also have a clock period. So if the clock is 10ns, and your set_output_delay -max 4.0, then you're also saying the FPGA needs to get it's data out by 6ns after the clock edge or you'll fail setup at the external device. So you are constraining the FPGA.

Quartus will modify I/O delay chains to try and meet this timing. (It will not phase-shift the clock, or promote/demote clock trees).

If you just use -max, then -min gets the same value. That is unrealistic though, and it is recommended to use both.

Thank you so much, Rysc.

You have explained the set_output_delay -max 4.0, and I totally understand it now.

Now, I come up with another question following your explanation, but just to the opposite:

If I have a 10ns clock, the external device's hold time is 4 ns, ignoring the board delay,then I set set_output_delay -min -4.0, so the FPGA should have its Tcomin = 4ns. In this case, am I constraining the FPGA to add delay to its output(if the original Tco < 4 ns)?

If my guess is correct, then:

You mentioned "Quartus will modify I/O delay chains to try and meet this timing. ", so if this constraint can make the FPGA adjust its I/O delay automatically, why is the programmable I/O buffer still provided by Altera? Is that an alternative manual way for the user to change the I/O timing? Still using my example above, say the the original Tco =1ns < 4 ns, we need to add at least 3ns to satisfy the 4ns external device hold time requirement. If after applying the constraint, the analyzer reports a negative slack for the hold(which means the Fitter tried to adjust the I/O delay,but failed to provide enough), shall I now insert the I/O buffer?

Thank you very much again!

--- Quote Start ---

Look at the TimeQuest User Guide on alterawiki.com about these constraints.

Yes, they do just tell the external delays(aka setup and hold, depending on how you look at it). But you also have a clock period. So if the clock is 10ns, and your set_output_delay -max 4.0, then you're also saying the FPGA needs to get it's data out by 6ns after the clock edge or you'll fail setup at the external device. So you are constraining the FPGA.

Quartus will modify I/O delay chains to try and meet this timing. (It will not phase-shift the clock, or promote/demote clock trees).

If you just use -max, then -min gets the same value. That is unrealistic though, and it is recommended to use both.

--- Quote End ---

Always look at your setup and hold relationship first. When you say the set_output_delay -min -4ns, does that mean the TCOmin = 4ns? It depends on the hold relationship. If the clocks are edge aligned(and most likely they are), then the hold relationship is 0ns. With a 0ns hold relationship, and an external delay of -4ns, then the FPGA needs to add at least 4ns of delay to get back to 0. So you're right, but it's important to think about the hold relationship, as you can create cases where it's not 0.

As for programmable I/O delay, depends what you mean. It can dynamically be programmable for interfaces that need to be dynamically adjusted. For example, you could have something that plugs into the FPGA and the I/O relationship is unknown, and the user has to dynamically adjust that and find the correct setting in system. (I've seen this with Flash interfaces where they could come from many vendors, all with different specs)

It's also programmable through the Assignment Editor. This isn't dynamic, just forcing it. Some users prefer doing this over timing assignments. (I've heard Xilinx doesn't adjust their I/O delay chains to meet timing, and the user has to do it, so it may come from that perspective). I've seen users try different settings in the lab and then force the delay chains, regardless of their timing constraints. It's also just a fail-safe in case the fitter makes the wrong choices.

Finally, in your example where the TCOmin is 4ns. That has to be at the Fast Corner to meet that. Let's say it meets that by being 4.5ns. In the Slow Corner, it may be twice that at 9ns, barely meeting the 10ns setup relationship. If there's a max output delay, it may be impossible to meet timing.

Another way I like to look at it is the the setup relationship - hold relationship is the data rate. So for a 10ns clock, with setup of 10 and hold relaitonship of 0ns, we're trying to move data every 10ns. The external delay's max - min is how much margin is chewed up external. So if set_output_delay -max 4ns and -min -1ns, then 4 - (-1) = 5ns, or half the margin is used externally, and the FPGA has a 5ns window to work with. Finally, there is the actual -max and -min values, which show where the FPGA must pass data through. (i.e. a -max 4 and -min -1 is different than a -max 6 -min 1, the FPGA must pass data through 2ns earlier in the second case). Just another way to look at them. Sometimes it makes it more clear, sometimes it's more confusing. :)

Excellent clarification,Rysc. Now I totally understand it.:D

Just curious about the case in your last example set_output_delay -min 1 ,

by setting that it assumes the external does not need any hold time theoretically because the Tcomin will be -1ns, is such a digital device not uncommon?

One more question: in case the FPGA can't satisfy the set_output_delay constraint(e.g. fall short of the hold check), I can use the I/O buffer to slightly increase the delay, but as you explained such tweak must be within the margin since I am also affecting the setup while doing this. with that being said, if the margin is very small I may end up with failure. Is there any other suggestion to work around this issue? maybe a structure change, or enabling I/O FF(i.e. useioff attribute)?

:evil:

--- Quote Start ---

Always look at your setup and hold relationship first. When you say the set_output_delay -min -4ns, does that mean the TCOmin = 4ns? It depends on the hold relationship. If the clocks are edge aligned(and most likely they are), then the hold relationship is 0ns. With a 0ns hold relationship, and an external delay of -4ns, then the FPGA needs to add at least 4ns of delay to get back to 0. So you're right, but it's important to think about the hold relationship, as you can create cases where it's not 0.

As for programmable I/O delay, depends what you mean. It can dynamically be programmable for interfaces that need to be dynamically adjusted. For example, you could have something that plugs into the FPGA and the I/O relationship is unknown, and the user has to dynamically adjust that and find the correct setting in system. (I've seen this with Flash interfaces where they could come from many vendors, all with different specs)

It's also programmable through the Assignment Editor. This isn't dynamic, just forcing it. Some users prefer doing this over timing assignments. (I've heard Xilinx doesn't adjust their I/O delay chains to meet timing, and the user has to do it, so it may come from that perspective). I've seen users try different settings in the lab and then force the delay chains, regardless of their timing constraints. It's also just a fail-safe in case the fitter makes the wrong choices.

Finally, in your example where the TCOmin is 4ns. That has to be at the Fast Corner to meet that. Let's say it meets that by being 4.5ns. In the Slow Corner, it may be twice that at 9ns, barely meeting the 10ns setup relationship. If there's a max output delay, it may be impossible to meet timing.

Another way I like to look at it is the the setup relationship - hold relationship is the data rate. So for a 10ns clock, with setup of 10 and hold relaitonship of 0ns, we're trying to move data every 10ns. The external delay's max - min is how much margin is chewed up external. So if set_output_delay -max 4ns and -min -1ns, then 4 - (-1) = 5ns, or half the margin is used externally, and the FPGA has a 5ns window to work with. Finally, there is the actual -max and -min values, which show where the FPGA must pass data through. (i.e. a -max 4 and -min -1 is different than a -max 6 -min 1, the FPGA must pass data through 2ns earlier in the second case). Just another way to look at them. Sometimes it makes it more clear, sometimes it's more confusing. :)

--- Quote End ---

For -min 1, I was just making it up, so I can't say it's uncommon or not. It's probably not, but I've seen about everything under the sun. Note that source-synchronous devices can spec "strange" tsu/th requirements, which when you work it out, relate to saying if the clock should be edge-aligned or center-aligned.

Quartus should be increasing the I/O buffer itself. If the requirements are physically impossible to meet, there may be a solution but it gets tricky. For example, if Quartus increases the I/O delay chains, they it increases the output Tco max/min, since the delay chains vary over PVT. By increasing this spread, you basically hurt timing. Another way to do it would be to manually shift the PLL output forward a bit. This pushes out the time the data comes out without increasing the max/min spread, since PLL shifts are PVT invariant. That's where it gets complicated. (And of course, there are scenarios where it just won't close timing, which is where faster speed grades, faster device families, high-speed transceivers, etc. all start to come into play)