Error (18496): The Output SCLK in pin 26 is too close to PLL clock input in pin 27

[Altera_Forum]

Hello everybody, 

 I am using the Max10 chip with the Quartus Prime 17.1. I am building a SPI interface for ADC. The input pin for my on-board quartz oscillator is the pin 27 (bank 2). I have designated pin 26 (bank 2) for a SPI clock output. When I try to compile the design I get the following error:  ++++++++++++++++++++++ Start Error Message ++++++++++++++++++ Error (18496): The Output SCLK in pin location 26 (pad_711) is too close to PLL clock input pin (clk_in) in pin location 27 (pad_0) Error (171000): Can't fit design in device Error: Quartus Prime Fitter was unsuccessful. 2 errors, 4 warnings  Error: Peak virtual memory: 909 megabytes  Error: Processing ended: Thu Apr 19 18:28:02 2018  Error: Elapsed time: 00:00:05  Error: Total CPU time (on all processors): 00:00:03 Error (293001): Quartus Prime Full Compilation was unsuccessful. 4 errors, 8 warnings +++++++++++++++++++++++ End Error Message ++++++++++++++++++  I have also tried fitting the design by moving the SPI clock output to other CLK pins (28,29) in the same bank, and I get the same error message. If I use pins which are not CLK pins (30,32,33) in the same bank or any other pin in different bank the design can compile succesfully.  Does anyone know why is Quartus giving this error?  Thanks in advance and Cheers,  Milos

[Altera_Forum]

The clock pins are dedicated inputs, not outputs, so to send a clock out, you don't use a clock pin.

[Altera_Forum]

The MAX10 clock inputs are also useable as general IO, but pin distance rules have to be observed.  

 You didn't tell why you wanted to use the said pins as SCK output. Technically, you'd either use any suitable IO pin, or in case of very critical timing (unlikely for SPI interface), a dedicated PLL output pin.  If you have already finished a PCB and want to check if the SCK output at pin 26 actually disturbs the input clock, you can disable the fitter check by specifying a TOOGLE_RATE of 0MHz for the pin in the pin planner or assignment editor.

[Altera_Forum]

Hello sstrell, 

 What you said is not correct. The "CLK" pins (26,27,28,29) can also be used as general purpose I/O. I have tried using the internal oscillator of the Max10 to generate the main clock from which the SPI clock is derived, and output SPI clock on the same pin (26). The design compiled and it was running. Also, when I placed the SPI clock output to a "CLK" pin in different bank, the design was able to compile. There seems to be a problem only when one "CLK" pin is used as an input from on-board oscillator and the other as a clock output, in the same bank.  Cheers, Milos

[Altera_Forum]

--- Quote Start ---  The MAX10 clock inputs are also useable as general IO, but pin distance rules have to be observed.   You didn't tell why you wanted to use the said pins as SCK output. Technically, you'd either use any suitable IO pin, or in case of very critical timing (unlikely for SPI interface), a dedicated PLL output pin.  If you have already finished a PCB and want to check if the SCK output at pin 26 actually disturbs the input clock, you can disable the fitter check by specifying a TOOGLE_RATE of 0MHz for the pin in the pin planner or assignment editor.  --- Quote End ---    As you have guessed, I have already finished the PCB and my SCK output is on pin 26, while quartz oscillator input is on pin 27. How exactly can I specify the TOOGLE_RATE, and how is this solving the problem? Sorry for the amateur questions.  Also, where can I get some documents explaining the pin distance rules you mentioned.  Cheers, Milos

[Altera_Forum]

Review the "MAX 10 FPGA Signal Integrity Design Guidelines", particularly paragraph "Guidelines: Clock and Data Input Signal for MAX 10 E144 Package". 

 Enter the Toggle_Rate in Pin Planner, the column must be possibly enabled before in context menu:   https://www.alteraforum.com/forum/attachment.php?attachmentid=15198   or enter a tcl command "set_instance_assignment -name IO_MAXIMUM_TOGGLE_RATE "0 MHz" -to clk_1m"

[Altera_Forum]

stmilos, 

 I don't want to sound like your mother, but this demonstrates why you should ALWAYS create a top level design in Quartus and do pin assignments BEFORE committing to hardware.

[Altera_Forum]

--- Quote Start ---  stmilos,  I don't want to sound like your mother, but this demonstrates why you should ALWAYS create a top level design in Quartus and do pin assignments BEFORE committing to hardware.  --- Quote End ---    One does not always completely finish the internal logic before the physical hardware, and I find these very specific restrictions horribly obscure and unexpected.  I'm having the exact same problem on a 10M02. I use a clock control block to switch between three clocks (the input clock and two output clocks of a single PLL), and it is accepted fine on its own, but when I try to use a second clock control block with the exact same inputs (just a different output) suddenly this error 18496 occurs. And a toggle rate of 0 MHz on the pin that is deemed 'too close' does not seem to help.

[TBarn2]

We have comae against this problem as well. We have an existing board design on which we are adding additional FPGA functionality that uses the two pins either side of the PLL clock input, pin 27 on an 10M04SCE144C8G device. We get errors like:

"Error (18496): The Output wifi_enable in pin location 28 (pad_828) is too close to PLL clock input pin (clk_24) in pin location 27 (pad_12)"

In our case these signals are rarely toggled, mainly just at power up, so we believe these shouldn't cause any issues.

We have tried adding:

"set_instance_assignment -name IO_MAXIMUM_TOGGLE_RATE "0 MHz" -to wifi_enable" to the projects *.qsf file, as mentioned above, however this has no effect, the errors are still reported. We are using Quartus18.1.0 Build 625 09/12/2018 SJ Lite Edition.

Doesn't the IO_MAXIMUM_TOGGLE_RATE setting work any more or could there be another reason why this does not mask the error ?

Terry

[TBarn2]

Some more on this. If I set our pin wifi_enable (pin 28) which is next the our pin clk_24Mhz (pin 27) to be an input rather than an output the quartus software does not produce any errors or even warnings. Although I realise having an output driven close to the FPGA is likely to produce more noise, I would have thought that the quartus software should at least produce a warning in this case ?

Anyway how can I override the "Error (18496):" for our design as I don't think this is going to cause us any issues and will, at least, allow us to proceed with development on the boards we have ?

[TBarn2]

Any response to this ? Doesn't the latest Quartus have some options to disable this error and make it a warning ?

If not can i somhow put in a request to add the ability for Quartus to ignore this error and make it a warning ? We need to use all of the pins available on this chip and have a number of lines that only toggle once at power up or else very infrequently and it seems that the Quatus software should allow us to use the 3 pins next to the clock input lines for output? Or are there serious issues in using these pins ? Alternatively is there some Opensource software we can use instead of Quartus ?

[TSute]

​I have actually the same problem. But I intentionlly want to drive the neighbour pin constant low. The pins are connected to GND on the PCB. This is the concept of Virtual GND Pins, which support  the clock Input and protect it from other neighbours. How can I drive the pin low without this error message from the fitter?

[TSute]

see: https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/solutions/rd06292005_106.html​

[CKPope]

I am tasked with getting our Quartus tools running for one of our university course offerings. The development board that is used was designed in 2015 and the Quartus Tools (Altera Quartus Prime v15.1) were used as part of the pin assignments and fitting etc. It has served us very well.

We have the board running with the an LED output driving pin 28 with no issues. But our Altera Quartus v15.1 tools have expired. So we are looking at migrating to the newer tools. But we need to override this Fitter problem.

Using newer versions of the Quartus tools (v16.1 and later), the same fitting error described above became evident.

Is there a tcl command that can be used to ignore this error?