Gated dedicated clock outputs

[Altera_Forum]

I'm currently not understanding an issue that turns up with my Stratix III EP3SL50 Device. 

 what i try to do:   In a PLL (altpll) I generate a 70 MHz clock from a 50 MHz clock. The resulting clock (output [0] of the PLL), I propagate to a regional clock gating buffer (altclkctrl) from where it should further be propagated to clock outputs (for external use).   The 50 MHz input clock is defined to be a clock net in the .sdc file.   what i get is the following type of error message (for all 4 outputs):   Warning: PLL "TGEN:TG|UsbSensPll:SP|altpll:altpll_component|UsbSensPll_altpll:auto_generated|pll1" output port clk[0] feeds output pin "SENSOR_CLK_P1~output" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance   How do I have to deal with this (I can't take direct PLL outputs as sugested, as I want to gate the clocks prior to output, but I think the dedicated altclkctrl should be fine for the job...)? Is there need for an additional clock definition (on the clock output pin)?

[Altera_Forum]

If you are using the output clock(s) as the external clock for a source synchronous output interface from the FPGA, then yes you will need to create a clock on the output port with the -source being the output pin from the PLL. This clock then becomes the target of the -clock option on your set_output_delay constraints for the source synchronous output interface. If you aren't using that clock to constrain anything to/from the FPGA, then you won't need to create a generated clock on the output port. 

 As for the Warning, you get that because you are gating the clock and not going directly to a dedicated clock output. Use derive_clock_uncertainty to set the uncertainty representing the jitter produced.

[Altera_Forum]

--- Quote Start ---  As for the Warning, you get that because you are gating the clock and not going directly to a dedicated clock output. Use derive_clock_uncertainty to set the uncertainty representing the jitter produced.  --- Quote End ---     Actually, the 70 MHz output is input to an image sensor array, from where I have a source synchronous I/F (data nand clock) back to the FPGA. So the output timing is not so important. Up to now, I used ordinary data pins for the clock outputs, but in a redesign I intend to use dedicated clock outputs as I have them available now due to design changes.   My understanding was to use the altclkctrl as a (gated) driver to a regional (upper left quarter) clock net which then directly drives the dedicated clock outputs (of bank 8C). The same construct (on another PLL output but with gating buffer, too) works perfectly with clocks used internally. I'm not worried about the jitter, but about not using an internal regional clock net.   May the increased jitter be systematic? (leading to asymmetric clock output duty clycles like 40/60 or someting like that)   Would it be preferrable to directly gate the clock output? (gating takes place during reset sensor only, so a non-perfect gating might be acceptable)

[Altera_Forum]

If you drive the clock out using a altddio_out component, the warning will go away.

[Altera_Forum]

--- Quote Start ---  If you drive the clock out using a altddio_out component, the warning will go away.  --- Quote End ---     Yep, this works perfectly concerning the warning, It's gone! I connected _l / _h data inputs to 0/1 and with that propageted the clock to the output. Thanks for the hint.   Compared to the previous version I now have additionally the DDIOOUTCELL_X25_Y51_N98 instance in my path, which is located at the pad, adding somewhat more than 1 ns to the time budget (which actually is not important). However the following point arises:   Do I get something (besides the mere satisfaction of the fitter warnings), is it just the same or does it cost me something (if yes, what)?

[Altera_Forum]

It aligns the clock with the output data in case of a source synchronous output bus. In a source synchronous output it would be disadvantageous to have the output clock come from the dedicated PLL output pins as the timing (over the PVT range) is quite different.

[Altera_Forum]

Hi, 

 I am having the same problem: Warning: PLL "PLL167MHz:PLL167MHz_Instance|altpll:altpll_component|PLL167MHz_altpll:auto_generated|pll1" output port clk[0] feeds output pin "SRAM1_clk_o~output" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance  I tried to change the location of the feeding clock of the PLL (I am currently designing the board, so feeding clock ports are not placed yet), but I always have this warning, I also tried to change the PLL assignment... But whatever I do, I have the same warning...  I've also read the application notes and the Cyclone III handbook, and when I do what is recomended, the warning still shows himself  How to fix this warning??

[Altera_Forum]

Apparently you are not on a dedicated clock output. To be sure, you'd have to check the pinout for the specific device you are using to find out what pins are dedicated clock outputs. Instead, you are using local routing to get to the output pin you have selected. The Warning you are receiving is just letting you know that you will have greater jitter on your clock output. To find out what that jitter is, you can use the "derive_clock_uncertainty" macro in TimeQuest. If you can live with this amount of jitter, then you can ignore the Warning. If not, then choose a different output pin.

[Altera_Forum]

Actually i am using a dedicated pll output pin of the PLL 1 block. I am aware that CLK0 ton CLK3 pins feeds the pll1 block. And i already use the derive clock uncertancy in a sdc file. I tried all combination of clk input and pll outputs but the problem always arrises. I really don t understand how to do it right, and i have had this problem with several designs for a long time

[Altera_Forum]

If that is the case, then I would suggest filing a Service Request with Altera.

[Altera_Forum]

The most likely explanation is that you have something in your design that prevents usage of a dedicated clock output. Something that hasn't been mentioned yet in your posts. Cyclone III normally hasn't problems with clock outputs.