constaint timing and ouput

[Altera_Forum]

Hi all, 

 I want to test contraints timing to understand TimeQuest and to verify the consequenses of using the tool . For that I have created a simple two ouputs PWM. The ouputs are similar and based on the same signal. I just want to delay one compared to the other by timing contraints. My aim: the first one arrives 5ns later than the second one.   I have written these contraints: set_output_delay -max -clock [get_clocks {clk_40_91mhz}] 1.500 [get_ports {sortie_pwm1}] set_output_delay -min -clock [get_clocks {clk_40_91mhz}] 1.000 [get_ports {sortie_pwm1}] set_output_delay -max -clock [get_clocks {clk_40_91mhz}] 5.500 [get_ports {sortie_pwm2}] set_output_delay -min -clock [get_clocks {clk_40_91mhz}] 5.000 [get_ports {sortie_pwm2}]   The project compiles without timing violation. On my scop I expect that sortie_pwm2 arrives about 4ns later than sortie_pwm1 but it is not the case.   I don't understand why. If somebody can help me ?   Thanks.   Pierre

[Altera_Forum]

set_output_delay does not directly tell the FPGA what to do, i.e. an output -max of 5.5 and -min of 5 does not mean the data will leave between 5-5.5ns. These constraints are saying what the external device is doing. So if, for example, your clock period is 25ns, then you have a setup relationship of 25ns and hold of 0ns. If the external max delay is 5.5ns, then the FPGA has to get its data out in 25-5.5 = 19.5ns. With a hold relationship of 0ns, then the external delay of 5ns means the FPGA could get its data out as fast as -5ns and it would still meet timing. Go to www.alterawiki.com, click on Popular Pages, and around 15 is one called TimeQuest User Guide. Read through the Getting Started section, including the I/O portion.

[Altera_Forum]

There is a subtlety here. Let us look at definitions of set_input_delay then that of set_output_delay. 

None of them means set a specific delay as we may first think...  set_input_delay: You are telling TimeQuest that data is offset from its arrived launching clock edge at fpga pins by min ~ max delay. i.e. TimeQuest to expect a skew of (max-min) and deal with it.   Naturally this offset is due to either external device (tCO) and/or board delays and accordingly you enter your figures.  set_output_delay:  you are telling TimeQuest to produce data offset with respect to the exiting latch clock edge but avoid any transitions from (max) before edge to (min) after edge. TimeQuest is free to produce a skew outside that timing window.  Again your figures for max/min would be derived from external board delays and external device tSU/tH requirements.    When output delay is based on tSU/tH of external device, the tool requires that tSU is entered as positive and tH as negative. This is further confusing... if you consider max is indeed max and min is indeed min relative to latch edge then min should be before max relative to edge. But SDC definition here is just weird, a common historic issue with software development.    Hence you are not really setting specific delay point from clock edge but defining the timing window that should have data settled within. if you set both max/min to zero you are saying: timing window is zero, feel free TimeQuest. But you wouldn't get zero skew yet timing could pass !!

[Altera_Forum]

I would actually argue Tsu/Th is the "weird" definition, although expect many will disagree. Tsu/Th describe when the data must be valid around the clock, but they both have the same sign and it's the name that tells you which direction its talking about. For example, if the numbers for a device were +3 and +2, you have no idea which is Tsu and which is Th. On the other hand, an input delay of -2 to +3 is a range and you know which one is the min and which one is the max. It's only one number, input delay, and it's given a range. I believe that would be the more normal way to describe something. (Imagine a thermometer where numbers above 0 and below 0 were both positive, and they needed a qualifying name to know which one you meant). 

It is weird though, in that most engineers have had years of Tsu/Th pushed onto them to the point it became second nature, and now the constraints don't match that convention. That being said, I agree with your write-up and realized I'm arguing over what could be described as "weird", so nevermind, I'm just distracting myself from doing real work. : )

[Altera_Forum]

Thanks for your answer. 

 I'm reading your document (TimeQuest_User). My understanding of timing constraints was clearly wrong.   set_ouput/input_delay do not set a timing value between ouputs (in my example) but indicate a windows in the course of which the data is allowed to change. The windows 'values are configured by input/oupout delay.   Great document Ryan.   Best regards   Pierre

[Altera_Forum]

I think the words "maximum" and "minimum" in the definition of output delay are quite confusing, or even misleading. 

 I use the following figure on slide 94 of Altera TimeQuest Timing Analyzer Online Training video to derive the output delay formulars:  http://www.alteraforum.com/forum/attachment.php?attachmentid=4932&stc=1&d=1319537862  (1) max output delay:  http://www.alteraforum.com/forum/attachment.php?attachmentid=4933&stc=1&d=1319537932   based on the above waveform, we have:  (B-A) - (C-A) = (D-C) - (D-B )  i.e., (B-A) - (C-A) + (D-B ) = (D-C)  (B-A) : output delay (C-A): Board Data delay (Tdata_PCB ) (D-B ) : Board Clock Skew (Tclk2-Tclk1ext)  For ASSP.DIN to be captured by ASSP.CLK, (D-C) must >= Tsu of ASSP Therefore, output delay - board data delay + board clock skew >= Tsu  output delay >= board data delay - board clock skew + Tsu  output delay max >= board delay (max) - board clock skew (min) + Tsu  From the above derivation, we can see:  (i) the so called "max" output delay is actually the minimum output delay we can set under the worst case (i.e., max board delay and min board clock skew) while still maintain the setup requrement. We can even set a larger value as the max output delay, just that it is a kind of over-constraint. Because by doing so, we move the data valid window further left, and Quartus will work harder to make Tco smaller.  (ii) the max output delay defined by the above formular is actually referenced to fpga.clk (delay from fpga.clk to fpga.dout). So why should we still use the virtual clock (ASSP.CLK) when specifying the max output delay?  (2) min output delay can be derived from the same waveform:  http://www.alteraforum.com/forum/attachment.php?attachmentid=4934&stc=1&d=1319539681  we have: (A-B ) - (D-B ) = (C-D)-(C-A)  i.e., (A-B ) - (D-B ) + (C-A)= (C-D)  (A-B ) : -output_delay (NOTE : by definition, output_delay is always latch clock edge - data arrival point. So it should always be B-A in the above waveform, even if data arrives after the latch edge)  (D-B ): Board Clock Skew (Tclk2-Tclk1ext) (C-A): Board Data delay (Tdata_PCB )  For correct operation, current data (ASSP.DIN) should not be captured by current latch edge (ASSP.CLK). Therefore (C-D) must >= Th.  -output_delay - Board clock skew + board data delay >= Th  output_delay <= board data delay - board clock skew - Th  output delay min <= board data delay (min) - board clock skew(max) - Th  Again, the same question:  (i) the so called "min" output delay is actually the maximum output delay we can set under the worst case (i.e., min board delay and max board clock skew) while still maintain the hold requrement. We can even set a smaller value, just that it is a kind of over-constraint.  (ii) the min output delay defined by the above formular is also referenced to FPGA.CLK. So do we still need use the virtual clock (ASSP.CLK) when using the above formular to specify the min output delay?   These are my personal opinions. Welcome any further discussion.

[Altera_Forum]

r figures for max/min would be derived