How to ignore error 18496 (Output ??? too close to PLL clock input)

[John-Philip]

Related to:

• Error (18496): The Output SCLK in pin 26 is too close to PLL clock input in pin 27 
• Fitter Pin Placement Constraint 
• MAX10 pin too close to PLL clock 
• Pin location is too close to PLL clock input pin 

None of the above solves the issue.

I have a MAX10 10M16SAE144C8G design that compiles perfectly fine in Quartus 18 (and it's working in hardware).  I'm trying to upgrade the project to Quartus 22 or 23, but Quartus complains: "Error (18496): The Output opRGB_R1 in pin location 28 (pad_7875) is too close to PLL clock input pin (ipCLK_25M) in pin location 27 (pad_9)".

The interfering pin is an LED that is turned on and then left on.  It cannot cause interference on the clock, because it doesn't toggle.

I've tried setting `set_instance_assignment -name IO_MAXIMUM_TOGGLE_RATE "0 MHz" -to opRGB_R1`, but no luck.  Same error.

I've tried applying the same setting to ipCLK_25M, just to check, but also no luck.

How do I tell Quartus that it should ignore that error and route the design anyway?  I'm willing to take the risk related to interference on the clock line.

[sstrell]

KDB articles say this was a bug fixed ages ago: https://www.intel.com/content/www/us/en/support/programmable/articles/000074027.html

So it's weird that you're running into it.

Obviously your board is built so you have to use that pin, but can you try moving the LED output location, compile, then move it back and compile again?

You could also try deleting your db and incremental_db folders to do a fresh compile from scratch.

[John-Philip]

If I move the pin, it compiles
If I then move it back, same error.

A clean build doesn't help -- same error.

I've attached a simplified version of the project -- maybe someone can reproduce the problem and then let me know what parameter to set...?

[FvM]

Hi,
I was assuming so far that IO_MAXIMUM_TOGGLE_RATE always handles the issue. But I learned from your example that it's not the case.

Apparently it's a MAX10_E144 specific problem. Intel/Altera has implemented an undocumented quartus.ini option to disable pll inclock rules for this device.

I don't feel legitimated to post it here, you'll need to ask your FAE unless Intel will publish it.

Best regards
Frank

[FvM]

Hi,

I guess thea reason why specific IO constraints have been set up for MAX10_E144 is relative large cross talk of adjacent pins with this package. Thus you should double check if your pin usage is safe before disabling IO rules. Should be o.k. for a static LED signal.

Regards
Frank

[John-Philip]

Yes.  I know.  I'm happy that it is safe.

How do I tell Quartus to ignore it?

[John-Philip]

I'll hunt around to see if I can find the "quartus.ini option to disable pll inclock rules"...

[FvM · Accepted solution]

Hi,
I see the fix has been already published

intel.it/content/dam/support/us/en/programmable/kdb/support/knowledge-center/tools/2016/quartus-16.1-0.01cb-readme.txt

[John-Philip]

Awesome -- it works!  Thank you

In case the link goes broken in future, the solution is:

1. Create a new file with name "quartus.ini" in current quartus project directory.
2. Add "disable_max10_e144_pll_inclk_io_rule=on".
3. Save and re-compile quartus project again.

[sstrell]

So I guess it wasn't fixed!

[John-Philip]

I agree with Quartus's policy -- it is a bad idea to have an output pin next to the clock input.  I don't think it's a bug -- I think it's a missing feature (i.e. the ability to easily override the check).
No matter -- I have the ability to override the check, so I'm very happy

[RichardTanSY_Intel]

I am glad that the issue has been resolved. 

FYI, this is the KDB mentioned. 

https://www.intel.com/content/www/us/en/support/programmable/articles/000074027.html

I checked the database, and it appears that this patch was restricted to specific customers with a specific Quartus version at that time and was not typically included in future releases.

This likely explains why you are still seeing the issue in later Quartus releases, and an INI file was created to address the problem.

Since a KDB article has been created and a workaround (using the INI) is available, it is unlikely that this issue will be fixed in future Quartus Standard releases.

Please use the INI file to resolve the issue.

Regards,

Richard Tan

[RichardTanSY_Intel]

As the issue has been resolved, I will transitioning this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out. Please login to https://supporttickets.intel.com/s/?language=en_US , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

The community users will be able to help you on your follow-up questions.

Thank you and have a great day!

Best Regards,

Richard Tan