Forum Discussion

Honored Contributor

17 years ago

set_output_delay -min / -max does not have intended effect

Hi,

Per earlier recommendations i have switched to TimeQuest in order to correctly constrain output signals in my design. The FPGA is a Cyclone II and i'm using Quartus II 7.1.

I'm trying to achieve correct timing for a source synchronous output bus that drives an external FIFO. I have a 48 MHz clock, a 16-bit data bus and a 'write'-signal. The external FIFO requires the following setup and hold timings:

data tsu_needed = 4ns

data th_needed = 5ns

write tsu_needed = 13ns

write th_needed = 5ns

Given the source synchronous interface, i'm using the following SDC Settings (the complete SDC file is attached):

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 13 [get_ports {N_SLWR}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -4 [get_ports {N_SLWR}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[15]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[15]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[14]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[14]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[13]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[13]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[12]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[12]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[11]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[11]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[10]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[10]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[9]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[9]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[8]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[8]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[7]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[7]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[6]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[6]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[5]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[5]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[4]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[4]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[3]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[3]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[2]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[2]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[1]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[1]}]

set_output_delay -add_delay -max -clock [get_clocks {CLK_OUT_48}] 4 [get_ports {DATA_OUT[0]}]

set_output_delay -add_delay -min -clock [get_clocks {CLK_OUT_48}] -5 [get_ports {DATA_OUT[0]}]

Unfortunately, the timings as measured by my Logic Analyzer attached to LAI pins on the FPGA shows that the following timings result:

data th_actual = 1.3ns

write th_actual = 2ns

Changing the -min time to something more negative does not affect the hold time a bit.

Any ideas where to start debugging this?

Thanks,

/John.

UlpiTest.zip1 KB

18 Replies

Altera_Forum
Honored Contributor
17 years ago
Very simple, the timing constraints can only achieve delays that are feasible within the given logic structure. The means to adjust the timing are very limited, mainly usage of different routing pathes and a rather small (around 0.5 ns maximum) additional output delay available with some FPGA families. I does neither cause structural changes, as moving registers from interal logic to output cells or vice versa nor adjust output drive strengths.

Above several ns delays usually can't be achieved by timing constraints without choosing an appropriate structure in advance respectively introducing structural changes manually. Another (probably better) way could be to use a phase shifted clock from a PLL.

Enabling physical synthesis may also help, but I would generally prefer a solution where the timing constraints are used to balance unavoidable routing delays rather than forcing a huge imbalance arbitrarily.
Altera_Forum
Honored Contributor
17 years ago
Just looking at the timing constraints, I don't see it as source synchronous, and think it might be set up incorrectly. Your clk_out_48 gets a create_clock assignment, which means a clock comes into it. If this is an output, create a generated_clock assignment on it, and the -source should be the PLL output name that is a generated clock(I'm assuming a PLL is driving this output). That will make a drastic change in your timing results, if that's how your circuit actually works. If everything is going into the output register, there is a fine grained output delay chain in Cyclone II(search for IOE programmable delay in the handbook to see the values), but I think they are too small to meet your delay requirement of padding the data by 5ns. The fitter might move the registers out of the IO cell to meet timing, but that's only once the constraints are correct.
Altera_Forum
Honored Contributor
17 years ago
Rysc:

I have changed my SDC but the clock to out delay does not change. I think the problem might be that the source synchronous clock is generated internally in the PLL while Quartus/TimeQuest appears to use the input clock to the PLL as reference. Since there is a path delay of 3.3ns from the input 48 MHz clock to the output 48MHz clock the timings appear to be some 3ns off (confirmed by my Logic Analyzer). The TimeQuest reports all show output delay min/max in relation to the input clock, not the output clock. This appears incorrect for a source-synchronous design?

Are PLL outputs phase locked to the PLL inputs? The reason i have a 48 MHz PLL output while the input clock is 48 MHz is that i'm generating a 48 MHz, 60 MHz and 120 MHz clock in the PLL and i want them all to be phase locked to each other. Since all clocks are phase locked i would get away with a single reset synchronization circuit for all three clocks.

--- Quote Start ---
Very simple, the timing constraints can only achieve delays that are feasible within the given logic structure. The means to adjust the timing are very limited, mainly usage of different routing pathes and a rather small (around 0.5 ns maximum) additional output delay available with some FPGA families. I does neither cause structural changes, as moving registers from interal logic to output cells or vice versa nor adjust output drive strengths.
--- Quote End ---

FvM: I have seen discussions about this in other threads (Brad, Rysc, FvM and others) and i believe the conclusion was that very large routing delays would be inserted as long as the output flops were not in the output cell. I believe an example project was created where 20 ns was correctly inserted.

My latest SDC file is attached.

Thanks,
/John
UlpiTest.zip1 KB
Altera_Forum
Honored Contributor
17 years ago
FYI: I have also tried using the -reference_pin option as explained in the Altera online example "TimeQuest Example: Basic Source Synchronous Output". This didn't help a bit but apparently this is because the approach suggested earlier to create a clock with create_clock for the output pin and then use it with set_output_delay should have the same effect (or none effect - as in my case...).

Note that the TimeQuest timing reports STILL use the CLK_IN_48 clock as reference. It looks like it ignores the 48 MHz PLL clock, perhaps because the PLL clock has the same frequency and phase as the input 48 clock.

I also tried to use the PLL in "source synchronous" mode but no improvement can be measured on my LA.

Any ideas how to continue?
Altera_Forum
Honored Contributor
17 years ago
You're source for the output generated clock seems to be a different name then the target of the PLL clocks. It still might work, just something I noticed. Everything will be related to the input clock, but since the data starts there and the clock going off chip starts there, they just cancel each other out. It's still correct that they start there.
(I've used reference_pin once, and though I got it to work, prefer putting a generated_clock on the output pin because it makes more sense to me and I have more control, since I've had cases where I needed to modify the clock constraint as it went off chip.)
Anyway, run the following:
report_timing -hold -detail full_path -npaths 10 -to [get_ports DATA_OUT*] -panel_name "h: data_out" -file "Data_Out_Hold.txt"
report_timing -setup -detail full_path -npaths 10 -to [get_ports DATA_OUT*] -panel_name "s: data_out" -file "Data_Out_setup.txt"
Then .zip up the two files and attach them. I'll get a much better sense of what's going on from that.
Altera_Forum
Honored Contributor
17 years ago
Hi Rysc,

I have attached the reports as well as my updated SDC file. I previously had some warnings in the Quartus build log that are now gone. I now get an interesting message in the 'warning' log which seems to indicate that a correct routing delay has been inserted:

Warning: 17 (of 9813) connections in the design require a large routing delay to achieve hold requirements. Please check the circuit's timing constraints and clocking methodology, especially multicycles and gated clocks.

Unfortunately, the DATA_OUT or N_SLWR setup and hold timings have not changed as seen on my Logic Analyzer. I'm using the LAI outputs but i would assume that the timings acquired via LAI should be the same as seen on the output pins?

Thanks,
/John.
UlpiTest5.zip7 KB
Altera_Forum
Honored Contributor
17 years ago
LAI output timings are not related to the IO timing at all(it would be impossible to do). LAI, I believe, is purely for looking at functional issues, not timing issues. You need to scope the outputs to see what is really happening.

Looking at the first hold path, it takes 17.244ns to get the data out, and the clock gets out in 3.373ns. This is at the slow model, where this really needs to be checked at the fast model too(which TimeQuest should automatically do, you're just not doing it when re-running TimeQuest), but I am quite certain it will make timing at that model to. So I think everything is working as you would like.

To be honest, I don't like adding huge delays like this and relying so much on min models. Not that they shouldn't work, but you're relying on the fitter to do something right everytime(and it should), but you're really not taking advantage of the source synchronous interface, whose major goal is to send the clock and data with almost identical delays, and just have the clock phase shifted so it's centered on the data eye.

For example, with the data, if you just inverted the clock in your design, either by having a tap of the PLL for it that phase-shifts it 180 degrees, or invert it on the output port(if you do the latter, you might have to add a -invert to the generated clock on the output port, I'm, not sure.) Now your output clock changes directly in the middle of the data you're sending. These track nicely over PVT, and that's why source-synchronous interfaces are required for high-speed I/O. It's just a suggestion, as again, what you have now looks right.
Altera_Forum
Honored Contributor
17 years ago
--- Quote Start ---
LAI output timings are not related to the IO timing at all(it would be impossible to do). LAI, I believe, is purely for looking at functional issues, not timing issues. You need to scope the outputs to see what is really happening.
--- Quote End ---

The LAI interface is in my experience not adding any significant delay to the monitored signals. I have used it extensively in the past to monitor timing related issues and the signals that came out from the LAI pins exactly have matched the actual output pins. The LAI gives much more flexibility and ease of use when checking timing on various boards because i don't need to solder wires onto the device pins etc.

I have also previously compared the LAI/LA timing with timing information captured via the SignalTap feature and they correlate very well. To make sure, i just put the scope on the signals and the scope verifies the timing information acquired via the LAI pins and displayed on my Logic Analyzer.

--- Quote Start ---
To be honest, I don't like adding huge delays like this and relying so much on min models. Not that they shouldn't work, but you're relying on the fitter to do something right everytime(and it should), but you're really not taking advantage of the source synchronous interface, whose major goal is to send the clock and data with almost identical delays, and just have the clock phase shifted so it's centered on the data eye.
--- Quote End ---

The problem is that the receiving external FIFO i'm writing to requires a SLWR signal tsu of 13ns and a tsu on DATA_OUT of 5ns. Both signals require a th of 4-5 ns. I have not been able to meed the external hold times (now around 2-3 ns). I could use the PLL to introduce a phase shift since i'm using it for the 48 MHz signal but i would run into the same issue on both the 60 MHz and 120 MHz buses which also will need to be properly constrained and i don't have more PLL outputs available. I was hoping i could rely on the fitter to take care of all these details for me but it seems to be less than straight-forward.

Perhaps i would need to go back and start playing with the clock signals again. The last time i tried this it ended up becoming very messy which is why i wanted an alternative approach in the first place.

I also tried to double the set_output_delay (min) from -5 to -10 but i only noticed a mere 1ns improvement in th. Right now i'm rather confused. It bothers me that i'm not able to achieve the correct timing information by using the current approach. If i can't trust set_output_delay to adjust the timing i'm back to fiddling with LCELLs etc which is a major mess, really.

Thanks,
/John.
Altera_Forum
Honored Contributor
17 years ago
Also, why are all output timings related to the input clock to the PLL and not to the actual clock the data is related to (in this case the source-synchronous interface)? It seems rather insane, especially in cases where the PLL output clock is not integer multiple of the PLL input clock. It seems useless to me to receive timing information that says that the clock to output delay is 17ns when the clock is not the one i'm interested in looking at.
Altera_Forum
Honored Contributor
17 years ago
--- Quote Start ---
FvM: I have seen discussions about this in other threads (Brad, Rysc, FvM and others) and i believe the conclusion was that very large routing delays would be inserted as long as the output flops were not in the output cell. I believe an example project was created where 20 ns was correctly inserted.
--- Quote End ---

Yes, I've noticed it. It's in deed a remarkable achievement of the Quartus II fitter. But to my opinion, it's far from a meaningful way to use timing constraints. I already made a remark regarding balanced timing. I think, the ideal balanced case is a design, that achieves the intended timing when all FPGA elements show their specified typical timing. Up to moderate clock frequencies, it wouldn't need timing constraints, cause the delay skew is below the available margin.

I understand, that this approach may be inapplicable for some designs. But this doesn't dispel my doubts about unnatural timing constraints.

Forum Discussion

set_output_delay -min / -max does not have intended effect

18 Replies

Recent Discussions

Failing IO buffer

Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.

Floating point operation on Cyclone 10 GX

Quartus/Signaltap complains about wrong version

Question about building projects in Eclipse when migrating from Quartus 17.1 to 23.1