Forum Discussion
Timing Slacks inside Altera IP
Hi,
I am compiling my design for the device 10AX115N2F40I2SG using:
Quartus Version: 22.1std.2 (Build 922, 07/20/2023, Standard Edition)
I am encountering timing violations (negative slack) on the clock a10_internal_oscillator_clock0 across all synthesis seeds. Due to these violations, I am unable to close timing on my design.
From my analysis, the failing paths appear to be internal to the Intel (Altera) IP, for example:
From:
ddr3_phy_wrapper48:ALTERA_DDR.ddr3_phy_wrapper_u|se_phy_master:u_qm2_phy|se_phy_master_altera_emif_221_zihdyxy:emif_0|se_phy_master_altera_emif_arch_nf_221_lnlpemi:arch|se_phy_master_altera_emif_arch_nf_221_lnlpemi_top:arch_inst|altera_emif_arch_nf_pll:pll_inst|iopll_bootstrap:gen_pll_dprio.inst_iopll_bootstrap|gen_pll_dprio.r_dprio_writedata_in_use~RTM
To:
|ddr3_phy_wrapper48:ALTERA_DDR.ddr3_phy_wrapper_u|se_phy_master:u_qm2_phy|se_phy_master_altera_emif_221_zihdyxy:emif_0|se_phy_master_altera_emif_arch_nf_221_lnlpemi:arch|se_phy_master_altera_emif_arch_nf_221_lnlpemi_top:arch_inst|altera_emif_arch_nf_pll:pll_inst|pll_inst~dprio_reg
My understanding is that this clock is only active during PLL calibration at device power-up and is not used during normal functional operation.
Given this, I would like to confirm whether it is safe and appropriate to constrain these paths as false paths. For example:
"set_false_path -from [get_clocks {a10_internal_oscillator_clock0}]"
Could you please advise if this approach is valid, or if there is a recommended way to properly constrain these paths?
I attached an image of the slacks.
8 Replies
- sstrell
Super Contributor
Are there any warnings or issues shown for the EMIF IP since this appears to be referring to one of the IOPLLs for the EMIF in an I/O bank? What is your refclk for the IP and what speed do you have the EMIF running at (internal and external)?
- Omer1
New Contributor
Hi sstrel,
I don't see any warnings or issues regarding the se_phy_master.qsys (EMIF IP).
The refclk is 266 Mhz. The EMIF running with clock of 1066.667 Mhz.
Attached in image.
BTW - I see that not all these slacks are related to the EMIF IP, but all are related to "iopll_bootstrap".
For example:
From:
tod_sync_pll:u_tod_sync_pll|tod_sync_pll_altera_iopll_221_fsgzxmq:iopll_0|altera_iopll:altera_iopll_i|iopll_bootstrap:iopll_bootstrap_inst|gen_pll_dprio.r_dprio_addr_in_use~RTM_1
To:
tod_sync_pll:u_tod_sync_pll|tod_sync_pll_altera_iopll_221_fsgzxmq:iopll_0|altera_iopll:altera_iopll_i|twentynm_iopll_ip:twentynm_pll|iopll_inst~dprio_reg
Attached an image.
I think we have an issue which related to the a10_internal_oscillator_clock0 (which is an internal clock that I don't have the ability to affect) and not to the EMIF IP.
- AdzimZM_Altera
Regular Contributor
Hi Omer1,
Please help to provide more information to help on clarify the issue.
I guess the a10_internal_oscillator_clock0 is a reference clock to EMIF IP.
Correct me if I'm wrong.
Any other instance that used same clock for the clock source in your design?
Is there any other instances that has been connected to EMIF IP?
Can you try to remove other IP and fit the EMIF IP first in the design?
Then observe if the timing violation is still there.
Regards,
Adzim
- Omer1
New Contributor
Hi Adzim,
- The a10_internal_oscillator_clock0 is not a reference clock to EMIF IP.
The a10_internal_oscillator_clock0 is internal clock (which is an internal clock that I don't have the ability to affect), and all our ref clocks are from PINs.
2. I have other instances that uses a10_internal_oscillator_clock0 clock, like this block:
tod_sync_pll_altera_iopll_221_fsgzxmq:iopll_0|altera_iopll:altera_iopll_i|twentynm_iopll_ip:twentynm_pll|iopll_inst~dprio_reg
So is looks like the issue is not related to the EMIF IP, but to a10_internal_oscillator_clock0.
I see that not all these slacks are related to the EMIF IP, but all are related to "iopll_bootstrap".
For example:
From:
tod_sync_pll:u_tod_sync_pll|tod_sync_pll_altera_iopll_221_fsgzxmq:iopll_0|altera_iopll:altera_iopll_i|iopll_bootstrap:iopll_bootstrap_inst|gen_pll_dprio.r_dprio_addr_in_use~RTM_1
To:
tod_sync_pll:u_tod_sync_pll|tod_sync_pll_altera_iopll_221_fsgzxmq:iopll_0|altera_iopll:altera_iopll_i|twentynm_iopll_ip:twentynm_pll|iopll_inst~dprio_reg
Attached an image.
I think we have an issue which related to the a10_internal_oscillator_clock0 (which is an internal clock that I don't have the ability to affect) and not to the EMIF IP.
- AdzimZM_Altera
Regular Contributor
Hi Omer1,
Please let me know if you still facing timing violation issue in your design.
Otherwise, I will step back and allow the community to assist with any future follow-up questions.
Thank you for engaging with us!
Regards,Adzim
- RichardT_altera
Super Contributor
Could you please provide the QAR design file (Project → Archive Project) so that I can investigate this further?
Kindly share the file with me via private message (PM).
Regards,
RIchard Tan- RichardT_altera
Super Contributor
Hi Omer1
Could you help to share the QAR design file (Project → Archive Project) so that I can investigate this further?
Kindly share the file with me via private message (PM).
Regards,
Richard Tan
- RichardT_altera
Super Contributor
Hi Omer1
As we have not receive any further response, we will continue to monitor this post for the next 5 days. If there are no further inquiries during this period, I will step back and allow the community to assist with any future follow-up questions.
Thank you for engaging with us!
Best regards,
Richard Tan