Output delay with or without clock shift

[Altera_Forum]

Here is a very simple example as attached. The output delays are set as follows. 

 set_output_delay -add_delay -max -clock [get_clocks {clk_pin}] 2.100 [get_ports {q[0]}] set_output_delay -add_delay -min -clock [get_clocks {clk_pin}] -0.700 [get_ports {q[0]}]   For the diagram without clock shift, its clock constraint is    create_generated_clock -name {clk_pin} -source [get_ports {clk}] -offset 0.00 [get_ports {clk_port}]   For the diagram with clock shift, its clock constraint is   create_generated_clock -name {clk_pin} -source [get_ports {clk}] -offset 0.500 [get_ports {clk_port}]   and its multi-cycle comstraint is   set_multicycle_path -from [get_registers {inst1[0]}] -to [get_ports {q[0]}] -setup -end 2   In reality, we don't know what clock shift we should set in advance because it is the clock delay from the source clock to the output clock pin. If we set the clock shift to any values, we might end up with wrong analysis results. It also affects output delay calculations because the output delay is with respect to the clock at the pin. Do you think that we should use the clock without shift? Or simply set the offset to 0.5ns as it was done in the doc "Constraining SOPC Builder Designers with TimeQuest" in the Altera Forum and the doc in Quartus-II handbook SOPC builder? Many thanks.

[Altera_Forum]

Seems you are mixing up clock offset with clock shift and delay. 

 Clock offset is normally the trace board delay from the output clock pin to the target device. This is typically in the order of 0.5 nanoseconds as used in many examples.  Clock shift is the phase shift between two clocks. If you are generating the clock with an internal PLL, TimeQuest already knows the PLL shift. Internal clock delays are also known by TimeQuest.  You get the same result with or without clock offset on the clock generation. You just must adjust the output delay constraint accordingly. The samples you mention use the clock offset, and then the offset is also added in the output constraint.

[Altera_Forum]

Yes, the output data and clock are created from the same input clock in the FPGA, so TimeQuest knows the max and min relationship between the two. Your generated clock only needs to say there is a clock going out this port so it can be referenced by your set_output_delay constraint. So no offset should be used.

[Altera_Forum]

Thanks, vjAlter and Rysc. 

 The output max/min delay is defined with respect to the clock at the output clock pin of FPGA. For example, output max delay = max data delay + tSUext - min clock delay (PCB clock skew).    set_output_delay -add_delay -max -clock [get_clocks {clk_pin}] 2.100 [get_ports {q[0]}]   Suppose that clk_pin is a clock generated by a PLL. How do you know that the delay from the PLL output to the clock output pin in adavance?   If the clock offset is calculated, the output max/min delay can be defined with respect to the offseted clock, output max delay should be defined as max data delay + tSUext. Then, set_output_delay -add_delay -max -clock offset_clock_pin (2.100 + clock offset) [get_ports {q[0]}].

[Altera_Forum]

--- Quote Start ---  Suppose that clk_pin is a clock generated by a PLL. How do you know that the delay from the PLL output to the clock output pin in adavance?  --- Quote End ---    you don't know, but TimeQuest does know. TimeQuest knows both the PLL phase shift and compensation, and the delay from the PLL to the output pin.    --- Quote Start ---   If the clock offset is calculated, the output max/min delay can be defined with respect to the offseted clock, output max delay should be defined as max data delay + tSUext. Then, set_output_delay -add_delay -max -clock offset_clock_pin (2.100 + clock offset) [get_ports {q[0]}].  --- Quote End ---    You are again mixing up internal with external clock delays. The internal delays are known by TimeQuest, you don't need to compute them or specify them.  The external delay (which is what is specified as clock offset in those examples you have seen) is, of course, not known by TimeQuest. But the external delay is not relevant for outputs. It doesn't matter how much time it takes from the clock pin to the target device, it only matters the maximum external skew between clock and data.  So you can do as Rysc suggests, forget about the offset and external delay altogether, and just add the maximum skew to the device Tsu and Th.  Or, if you want, you can use offset as in those examples. But again, this is only the external delay, not the internal one. If you use the offset in the clock generation, you must add it also in the output constraints.  You don't gain anything by using the offset for outputs. The only reason to use it is for the input constraints, because the external delay does matter for inputs.

[Altera_Forum]

vjAlter,  

 Thank you very much indeed.   set_output_delay -add_delay -max -clock [get_clocks {ref_clk_pin}] output_max_delay [get_ports {q[0]}] [1]   In the above equation, it seems that the clock at ref_clk_pin is irrelevant to the output_max_delay. However, they are not independent. Output_max_delay is caluculted as max_data_delay + tSUext –min_clock_delay, where min_clock_delay is the delay from ref_clk_pin to the clock pin of the external device. If you change the equation as follows for example,   set_output_delay -add_delay -max -clock [get_clocks {ref_clk_pin2}] output_max_delay2 [get_ports {q[0]}] [2]   then output_max_delay2 = max_data_delay + tSUext – min_clock_delay2, where min_clock_delay2 is the delay from ref_clk_pin2 to the clock pin of the external device.   What I said earlier is that when we configure a PLL, we have to consider the delay from the output of the PLL to ref_clk_pin or to ref_clk_pin2. We can't simply put a value of output_max_delay there without considering the above 3 factors. As a result, when we change from equation [1] to equation [2], we have to re-calculate the output_max_delay value and have to adjust the PLL phase shift to generate ref_clk_pin2 accordingly. How to adjust the phase shift has to be through trial and error.

[Altera_Forum]

What do you mean by ref_clk_pin and ref_clk_pin2? Why do you have two different output clocks? Are you using a differential clock, or you still didn't define the board pinout? 

 Or you mean two different generated clocks, at the same pin but with different generated clock parameters?

[Altera_Forum]

"What do you mean by ref_clk_pin and ref_clk_pin2? Why do you have two different output clocks? Are you using a differential clock, or you still didn't define the board pinout? Or you mean two different generated clocks, at the same pin but with different generated clock parameters?" 

 For example, the ref_clk_pin and ref_clk_pin2 could the clock at the clock output pin of the FPGA device and the clock at the clock input pin of the external device, recpectively. They could be two clocks in two different places. When you set your constraints, you only use one of them.   What I meant is that if you move the reference clock to a different point when you set your constraints, those three things have to be considered together.

[Altera_Forum]

--- Quote Start ---  For example, the ref_clk_pin and ref_clk_pin2 could the clock at the clock output pin of the FPGA device and the clock at the clock input pin of the external device, recpectively. They could be two clocks in two different places. When you set your constraints, you only use one of them.   What I meant is that if you move the reference clock to a different point when you set your constraints, those three things have to be considered together.  --- Quote End ---    If you change the reference clock from the FPGA pin to the target device pin, you also change the output constraints. But this doesn't affect TimeQuest, it is just a different conventional point of view. In both cases TimeQuest would compute the same timing, you would get the same slack, and the ideal PLL phase shift would be identical.  Let's say that you consider the reference clock at the target device. You then add the offset parameter at the clock generation. This moves the clock timing from the FPGA to the target device. But then you also must move the data output from the FPGA pins to the target. You do this by adding the external delay to the output constraints:  create_generated_clock -offset ExternalClockDelay ... set_output_delay -max [expr tSUext + MaxDataExtDelay + clockExtDelaySkew] ...  If you consider the reference clock at the FPGA pin, as Rysc recommends, you don't use the offset parameter. But you don't add the external delay to the output constraint either, only the external delay skew:  create_generated_clock ... (no offset parameter) set_output_delay -max [expr tSUext + MaxExtDelaySkew] ...  Both constraints are technically the same for TimeQuest. It is just two different ways to specify the same thing. What always matters is the relation between clock and data, this gives you the setup and hold slack. And in both cases the relation between clock and data is the same.

[Altera_Forum]

vjAlter,  

 I really appreciate your answers/comments. It is nearly to the point where we reach the conclusion.    The following is just minor things.    "create_generated_clock -offset ExternalClockDelay ... set_output_delay -max [expr tSUext + MaxDataExtDelay + clockExtDelaySkew] ..."   I think that it should be like   create_generated_clock clk_at_ext_device -offset min_ExternalClockDelay ... set_output_delay -clock clk_at_ext_device -max [expr tSUext + MaxDataExtDelay] ...   For  "create_generated_clock ... (no offset parameter) set_output_delay -max [expr tSUext + MaxExtDelaySkew] ..."   I think that it should be    create_generated_clock ... (no offset parameter) set_output_delay -max [expr tSUext + MaxExtDelaySkew - Min_Clock_PCB_delay] ...  The TimeQuest uses 2 different clocks, one for the source register (output register) - I call it clk, and the other for the external device such as SSRAM - I call it ref_clk, for timing analysis. We need a PLL to create clk and ref_clk. The phase shift between them is not known in advance. Before we set input/output constraints, we need to create clk and ref_clk or configure the PLL. When we create ref_clk or configure the PLL, we only can provide estimated values for the phase shift. Is my point clear?   Many thanks

[Altera_Forum]

--- Quote Start ---  I think that it should be like   create_generated_clock clk_at_ext_device -offset min_ExternalClockDelay ... set_output_delay -clock clk_at_ext_device -max [expr tSUext + MaxDataExtDelay] ...   --- Quote End ---    It is the same thing. Once again, you must think in terms of the relation between clock and data. The relation between clock and data depends here on the external delay skew.  So it is the same if you include the skew at the offset parameter, or at the output constraint, or half on each one of them. The absolute numbers at the clock generation and at the output constraints are not significant. Only the relation between both of them is.    --- Quote Start ---  create_generated_clock ... (no offset parameter) set_output_delay -max [expr tSUext + MaxExtDelaySkew - Min_Clock_PCB_delay] ...  --- Quote End ---    No, this is wrong. If you don't offset the clock at the clock generation, then you can't offset the constraint. The only thing you add to the external tSU is the worst external delay skew (skew only, no absolute delay).    --- Quote Start ---  We need a PLL to create clk and ref_clk. The phase shift between them is not known in advance. Before we set input/output constraints, we need to create clk and ref_clk or configure the PLL.  --- Quote End ---    Yes, that is correct. You can't know the optimum PLL phase shift before you do a timing analysis. But this is not trial and error. It is just a matter of doing timing analysis only once.  You do the following. You first make a compilation and timing analysis without any PLL phase shift. The TimeQuest report would tell you then, what is your maximum and mimum clock to output at the FPGA. It would also tell you the I/O setup and hold slack. You use these reports to compute your ideal PLL phase shift.  For this method to work you must use Fast I/O registers for your I/O ports. Otherwise the timing might change on each compilation. Using Fast I/O registers is recommended anyway to reduce skew as much as possible.

[Altera_Forum]

Quote: 

create_generated_clock ... (no offset parameter) set_output_delay -max [expr tSUext + MaxExtDelaySkew - Min_Clock_PCB_delay] ...  "No, this is wrong. If you don't offset the clock at the clock generation, then you can't offset the constraint. The only thing you add to the external tSU is the worst external delay skew (skew only, no absolute delay)."   To be exactly, it should   set_output_delay -clock clk_at_FPGA_clock_pin -max [expr tSUext + MaxExtDelaySkew - Min_Clock_PCB_delay] ...    The above equation is from the Altera documentation.   "For this method to work you must use Fast I/O registers for your I/O ports. Otherwise the timing might change on each compilation. Using Fast I/O registers is recommended anyway to reduce skew as much as possible."   If I use global clock network and dedicated clock pins, do you think that fast I/O pins are still necessary?   Thank you very much indeed.

[Altera_Forum]

--- Quote Start ---  create_generated_clock ... (no offset parameter)...  To be exactly, it should  set_output_delay -clock clk_at_FPGA_clock_pin -max [expr tSUext + MaxExtDelaySkew - Min_Clock_PCB_delay] ...    The above equation is from the Altera documentation.  --- Quote End ---    I don't know where in the Altera documentation have you seen that. If you are talking about the example in the "Using SOPC Builder with the Quartus II Software" chapter, then once again, that example uses an offset parameter in the create_generated_clock command.  So, as I was saying. If you offset the clock on the create_generated_clock command, then you offset the data as well on the set_output_delay constraint. If you don't offset the clock (no offset parameter), then you don't offset the data either.  Adding an offset to the data, but not to the clock, would result in wrong timing analysis.     --- Quote Start ---  If I use global clock network and dedicated clock pins, do you think that fast I/O pins are still necessary?  --- Quote End ---     Yes, it is still recommended. The problem is not the clock, but the different data delay caused by the placing of the registers that drive your data pins. If you are not using fast I/O, then Quartus might place your I/O data registers anywhere on the FPGA logic array.

[Altera_Forum]

Thanks. 

 "Yes, it is still recommended. The problem is not the clock, but the different data delay caused by the placing of the registers that drive your data pins. If you are not using fast I/O, then Quartus might place your I/O data registers anywhere on the FPGA logic array."   I did some experiments before and I found that for the most critical paths there were no timing difference at all before and after assigning fast input/output registers. Do you think that Quartus-II would automatically assigns fast I/O registers to the I/Os on the most critical paths when and where necessary?    I suppose that for bidirectional I/Os we have to assign them to both fast input registers and fast output registers if they are required. With the assignment editor, there is no obvious way to check if you have assigned fast I/O registers to individual elements of an array after you assigned the fast I/O registers to the array.

[Altera_Forum]

--- Quote Start ---  I did some experiments before and I found that for the most critical paths there were no timing difference at all before and after assigning fast input/output registers. Do you think that Quartus-II would automatically assigns fast I/O registers to the I/Os on the most critical paths when and where necessary?   --- Quote End ---    Usually fast I/O makes a significant difference. But it depends on many factors.   See the fitter report for checking which pins were actually assigned Fast I/O registers.    --- Quote Start ---  I suppose that for bidirectional I/Os we have to assign them to both fast input registers and fast output registers if they are required.  --- Quote End ---    Yes, and you might want to use Fast Output Enable as well.

[Altera_Forum]

Answer to my previous question, "Do you think that Quartus-II would automatically assigns fast I/O registers to the I/Os on the most critical paths when and where necessary?", is Yes. 

 From Compilation report - Fitter - Resource Section - Bidir Pins, Quartus-II would automatically assigns fast I/O registers and fast Output enable registers to the bidir I/Os on the most critical paths.   I would like to close this thread. I really appreciate your time, patience and efforts. Thank you very much indeed once again. Alll the best.