CLK-30028 - Invalid Generated Clock

[OrF]

Hi

I'm trying to define generated clock out of the pll.

and I get the following violation notification "CLK-30028: Invalid Generated Clock"

https://www.intel.la/content/www/xl/es/programmable/quartushelp/current/index.htm#da_rules/clk_30028.htm

since I'm sure the source clock and the target are coming to and out of the pll ( I don't get an error notification about the pin location )

my guess is that the issue is that " I need specify clock latency between clock and target."

I see the PLL IP sdc is loaded , any way I can debug it and understand what is the root cause ? 

I'm not using derive_pll_clocks command (and I dont want to use it ) 

Status:		FAIL
Severity:		High
Number of violations: 	1
Rule Parameters:      	max_violations = 5000
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; CLK-30028 - Invalid Generated Clock                                                                                                                                                                        ;
+---------+------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------+--------+
; Clock   ; Target                                                                             ; Reason                                                                                             ; Waived ;
+---------+------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------+--------+
; pll_clk ; step_ana_pll_i|iopll_0|stratix10_altera_iopll_i|s10_iopll.fourteennm_pll|outclk[0] ; No paths exist between the clock target and its clock source.  Assuming zero source clock latency. ;        ;
+---------+------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------+--------+

[sstrell]

What is your target device and why do you not want to use derive_pll_clocks (which is applied automatically in recent devices anyway)?

Does your clock report show the PLL output clock(s) correctly and what you expect?

[OrF]

1.My Target device is Stratix 10M .

2. Yes the Clocks are correct . in the report.

3. the reason I'm not using since I'm using derive_pll_clocks   Synplify Premier for the synthesis stage . 

[FvM]

A pll clock is no generated clock, thus the error.

[OrF]

As far as I see , and know output clock of pll is a generated clock.

https://www.intel.com/content/www/us/en/docs/programmable/683068/18-1/creating-generated-clocks-create-generated.html

"You apply generated clocks most commonly on the outputs of PLLs"

https://www.intel.com/content/www/us/en/docs/programmable/683068/18-1/deriving-pll-clocks.html

"The Derive PLL Clocks (derive_pll_clocks) constraint automatically creates clocks for each output of any PLL in your design. derive_pll_clocks detects your current PLL settings and automatically creates generated clocks on the outputs of every PLL by calling the create_generated_clock command."

[sstrell]

I'm not sure why the Design Assistant is calling this out, but since you're using a 3rd-party tool, you should issue a write_sdc command (or choose the option in the Timing Analyzer) to write out a full .sdc file for use by the other tool that will include the correct create_generated_clock constraints.

Other than that, if your timing analysis is accurate and you are closing timing, I'd ignore the DA.

[OrF]

the 3rd-party tool is for the Synthesis Part not for the P&R and timing closure . therefore I dont see the point to provide the sdc to the 3rd-party tool , even though I did generated the sdc, and looking at it I didn't find any additional constraints . 

this issues DOES effect the timing calculation since it doesn't take into account the the timing delay from the input of the pll to the output of the pll. 

[sstrell]

Something is wrong with your PLL implementation or instantiation then.  You may want to post a .qar here for support to look at your project.

[roeekalinsky]

Quartus doesn't even support derive_pll_clocks with Stratix 10 and Agilex.  Quartus supports derive_pll_clocks for Arria 10, Cyclone 10 GX, and earlier device families.  But for some perplexing reason Intel/Altera decided not to support it starting with Stratix 10.

Where derive_pll_clocks is supported, it is certainly the preferred method for constraining PLL output clocks, being the simplest method for the user and the least error prone.  It looks at the configuration of each PLL instance and automatically translates that to the correct create_generated_clock constraints.  No good reason not to use it, if supported.  But for Stratix 10 and Agilex it's not supported, so that's moot.

In the absence of derive_pll_clocks, you do need create_generated_clock constraints for the PLL output clocks.

If you instantiate your IOPLL via wizard-generated IP, then the IP will include the necessary constraints.

If you manually instantiate your IOPLL atom without making use of the wizard-generated IP, then you do need to also manually add the appropriate create_generated_clock constraints.  And make sure they're correct for your PLL configuration!  Quartus won't necessarily complain if they don't match the PLL configuration, and then your static timing analysis will just be wrong.

[sstrell]

derive_pll_clocks is supported with the newer devices, you just don't need to explicitly put it in your .sdc file anymore.  The generated clock constraints are automatically created.

[roeekalinsky]

@sstrell, that doesn't appear to be the case.  Have you tried it?  I just tried it again to confirm.  Quartus is definitely not automatically creating generated clock constraints for PLL clocks from a hand-instantiated IOPLL atom in Stratix 10 or Agilex.  Without user-added create_generated_clock constraints, the PLL clocks remain unconstrained.

This can be confirmed in multiple places:

• During the flow, Quartus rightly issues "Warning (332060): .... <name> was determined to be a clock but was found without an associated clock assignment" for each used PLL clock.
• During the flow, the PLL clocks don't show up in the "Info (332111)" tables that list the constrained clocks found in the design and their periods.
• In the STA report, in the "Clocks" table, the PLL clocks don't show up.
• In the STA report, in the "Unconstrained Paths Summary" table, you can see them counted in the "Unconstrained Clocks" count.
• In the STA report, in the "Clock Status Summary" table, they explicitly show up with Status "Unconstrained" .
• In the STA report, paths in these clock domains aren't analyzed.
• Etc.

[sstrell]

I've never not used the IP Parameter Editor for a PLL, so I don't doubt you.

[roeekalinsky]

If you're curious:  With the IP Parameter Editor, have a look at the SDC file and related TCL scripts that it generates.  That's where your create_generated_clocks constraints are coming from.

[OrF]

I've used Wizard-Generated IP ! , and I do have the sdc for the pll !.

I do see the ip.sdc in the sdc files list .

I will check if I can upload the archive project and post it here .