Hello. I have tried to wrap my brain around the documentation describing "set_output_delay", but I just don't seem to get it. My brain thinks like this: "Relative to the rising-edge of my output clock, the output data needs to be valid after 1 ns and remain valid for 2 ns". The documentation describes this: "The maximum output delay (-max) is used for clock setup checks or recovery checks and the minimum output delay (-min) is used for clock hold checks or removal checks. " So to me (please correct me if I'm wrong), "setup" sounds like the earliest time the data needs to be valid, and "hold" sounds like where the data is no longer required to be valid....But datasheets usually define setup as the time to the left of the clock, and hold as the time to the right of the clock. Since the valid window is to the right, one of these values should be negative? set_output_delay -max -1 set_output_delay -min 3 am I even close?

You need to start with Ryan Scoville's excellent tutorial on using TimeQuest. Maybe someone can post a link for this?

http://www.alterawiki.com/wiki/timequest_user_guide

Thanks for the plug, gj_leeson. :) http://www.alterawiki.com/wiki/timequest_user_guide It's probably better explained in the document, but here goes a condensed version. First, I think of set_output_delay as if it were describing a circuit. So if you have: create_clock -period 10.0 -name fpga_clk [get_ports fpga_clk] derive_pll_clocks ;#Let's say fpga_clk drives a PLL but the output is also 10ns create_clock -period 10.0 -name ext_clk ;# This is a virtual clock, because it's not applied to anything physical inside the design set_output_delay -max 3.0 -clock ext_clk [get_ports {dout[*]}] set_output_delay -min -1.0 -clock ext_clk [get_ports {dout[*]}] The set_output_delay constraint says there is an external register who'd D port is driven by dout[*] and who's CLK port is driven by ext_clk. Before even worrying about the -max/-min values, note that we know have a reg to reg transfer, where the launch register is the output register in the IO cell and is driven by the PLL clock, and the latch register is this one you've just described in your constraint. They are both driven by 10ns clocks, so the default setup relationship is 10ns and the hold is 0ns. We can do timing analysis like any reg to reg path. The -max and -min values state what the external max and min delays are to this external register. Looking at -max 3.0 since it's easier to understand, this says there is a 3ns delay to the external register. Since we have a 10ns setup relationship, then the FPGA must get the signal out dout[*] ports by time 7ns or it will fail setup. You can think of this simple case to be like a Tco requirement of 7ns. (There are cases where Tco isn't very good, but most of them line up nicely). I think one of the really hard things to grasp is that this is all dependent on the clock rates. So if someone asks me if "set_output_delay -max 3.0..." is a tight constraint, it all depends. If the clock period is 50ns, then yes, it's very easy. If it's 5ns, it's difficult. Also note that the -max value usually lines up with the Tsu requriement of the external device. So if the Tsu were 2.7ns, and the max board trace delay was 0.3ns, then we would do a -max of 3ns. The -min value works similarly stating that the external delay could be as short as -1ns. Since our hold relationship between the clocks is 0ns, the data must get across the interface in 0ns. So if the external delay is -1ns, then the FPGA must be at least +1ns to meet timing. In this case, the min value usually matches up to the negative of the external devices hold relationship. So, if your external device had a hold relationship of 1.1ns, and the board trace delay could be as fast as 0.1ns, then the external delay is (-1.1 + 0.1) = -1ns. Hope that helps.

Thank you very much for the explanation and I will read through that guide. I'm closing in on understanding, but I'm still not there. One thing that confuses me about your post is "Looking at -max 3.0 ... then the FPGA must get the signal out dout[*] ports by time 7ns of it will fail setup". In my example scenario, the external device is expecting these events at its input pins: t=0.0, clock edge t= (0.0,1.0) data does not need to be valid. t = [1.0, 3.0] data must be valid. t = (3.0,10.0) data does not need to be valid. So when you say "get the signal out by 7ns", what does that mean? If the data isn't valid until 7ns, my external device will not work. Am I misinterpreting what you are saying?

The simplest way is to use the equation: set_output_delay -max tSU set_outpt_delay -min -tH ( minus tH) This applies when clock and data go together with same delay what might confuse here is that for set_input_delay we give offset relative to launch edge for set_ouput_delay we give offset relative to latch edge

set_output_delay explained for dummies | Altera Community

14 Replies

Altera_Forum
Honored Contributor
9 years ago
Yes, I'm just saying it's unlikely you'll make timing. The delay chains only make it longer. They can't make the delay negative. You can shift your launch clock back with a PLL and use multicycles to say the data is launched before 0ns, but I don't think that really makes sense.
Altera_Forum
Honored Contributor
9 years ago
Isn't pushing the output clock forward time equivalent to pushing the data backwards in time? Why wouldn't that make sense?

I thought I had it, but I think I'm back to being confused. I guess I'm still confused as to why anything needs to be pushed negative in time. If the clock is output a time zero, and the data needs to arrive at t=1.0ns, wouldn't the proper skewing be that I need to add positive delay to the data and no delay to the clock?
Altera_Forum
Honored Contributor
9 years ago
The ideal clock occurs at both the FPGA and the external device at times 0ns, 10ns, etc. If the FPGA needs to get its data out within 1ns, then making the clock delay to the external device longer would help with this setup, but the clock delay to the external device is outside the FPGA, i.e. the FPGA fit can't affect that. The only things the FPGA can affect are the clock coming into the FPGA to the output register(launch clock path) and the delay from the register to the output port(data path). These two things make up the Data Arrival Path, and we essentially want them to be less than 1ns.

I recommend not spending a lot of time on hypotheticals and instead figure out your specific timing case. There are all sorts of ways you can confuse yourself with hypotheticals that are not worth the time.
Altera_Forum
Honored Contributor
9 years ago
Ah okay. Your post has made me realize that I was thinking the data would arrive too early (and maybe/maybe-not going invalid before 3.0 ns) while I think you were implying it would probably arrive too late to meet the 1.0 ns requirement.

In super general concepts: The FPGA data output is going to have its own output-valid window relative to that register's clock. I need to do whatever it takes to make sure the output valid window overlaps the downstream's devices input valid window (delay either clock or data, as appropriate). I should account for PCB delays and length-mismatches as well.

Forum Discussion

set_output_delay explained for dummies

14 Replies

Recent Discussions

licensing.altera.com never worked

NiosV and juart-terminal

NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10)

JTAG_UART stuck in printf

Ashling IDE scripted project creation