Fitter Pin Placement Constraint

[CKPope]

Hello,

I am a Lab Instructor at the University of Waterloo.

I have to provide some background context for the situation we now have.
An in-house board was developed way back when Quartus was still a part of Altera. Quartus was at v15.1. The pinout for the MAX10 FPGA was chosen and confirmed by the Fitter to be acceptable and the PCB was then designed and PCB Assemblies were made for numerous labs.

We have continued to use the Quartus v15.1 tools for the FPGA-related course using this board.

Starting with v16.1 and so on, the Fitter pin-placement rules have changed and the FPGA compiles no longer complete because one of the output pins (for driving an LED) is placed beside a PLL input pin.

The license for the v15.1 tools has finally expired and we are forced to move on to the newer tools.

Is there a setting somewhere with the Fitter, to ignore this placement constraint for our situation?

The Led pins are seldom changed and with the earlier v15.1 tools, there were no operational errors.

Thank you for your time,
kind regards,

Charles

[sstrell]

The pin assignments should have been back annotated so that they would be written to the .qsf file.  If that was not done, you can create manual assignments in the Pin Planner to match what you have set up on the board.  Those will get written to the .qsf so they don't change during future compiles.

As for the tools, you can use the Lite edition for free for Max 10 devices.  Any recent version will work.

[CKPope]

Sorry,  but I think there might be a misunderstanding....

The pins were pre-assigned with the pin locations when the Quartus v15.1 tools. Those are in the .qsf file already. Everything compiled OK and the pin locations were used and re-used in various courses where the logic inside the FPGA was changed but the pin locations were always maintained in the same locations.

Moving on to later versions of Quartus but still using the .qsf info from before, the designs created previously with the v15.1 tools, the designs no longer compile because of a Fitter error report. The same pin locations are used and the same FPGA logic is used. But the failure to compile arises when the Fitter (with the later version of Quartus) stops the compile because of the placement of one pin assignment (LED[1]).

So, since I have a board design that was proven with v15.1 tools and that the newer version tools complain with a Fitter error during a design compile, is there a setting that can force the Fitter to ignore the pin assignment error and still complete a design compile?

Charles

[sstrell]

That's very strange.  What's the exact error you are getting?

[CKPope]

Hi SSTRELL

The above compilation result was from using the v18.1 Lite tools.

The same error occurs when using the v18.1 Pin Planner.

When the same design above was compiled with the v15.1 tools, no such Fitter error occurred.

Any ideas are most appreciated.

Charles.

[sstrell]

There's a patch to fix this in 16.1 at least:

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

This article says it was fixed in 17.0, so not sure why you're seeing it:

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

Have you tried any newer versions of Quartus?

[CKPope]

Thank you for that info.

You sent two links. The first one looks like it is more "in line" with the situation that I am raising.

The second seems to apply more to the case where pins can be reassigned for an FPGA project.

Thank you VERY MUCH for this info. I checked the READ_ME file contents for the first link and it mentions that a patch for v16.1 is required. I don't have the v16.1 tools on site but I have the v18.1 tools.

But I did try creating the quartus.ini file with the "disable....." instruction inside it, with the hope that it would work for the version of Quartus (v18.1)....... but NOPE .

The patch is definitely required for v16.1 tools.

But I can't find the v16.1 tools or any patch for later tool versions on the Intel FPGA s/w download site..

I don't know if you are able to provide any additional info to me or if I could could add something to a TCL file, but anything would be very appreciated.

Charles

[sstrell]

16.1 is no longer available for download.  The second link implies that this was a bug that was fixed in 17.0.  So the fact that you are seeing it in a newer version is disturbing.

[ShengN_Intel]

Hi,

There is a restriction rule implemented into quartus from ver 16.0 and above for MAX10 E144 package device. Customer need to avoid output(GPIO) port placed beside PLL inclk.

Try to delete the placement location and instead use the Quartus Auto-Fit placement location. Or manually assign the location of the affected pin away from a PLL clock input pin in Assignment Editor.

https://www.intel.com/content/www/us/en/support/programmable/articles/000087348.html This KDB indicates that previously the Error (18496) can be seen even with Quartus Auto-Fit placement location but had been resolved since ver 17.0

Thanks,

Best Regards,

Sheng

[CKPope · Accepted solution]

Thank you !

Your work-around solution worked !!!!

All of the FPGA pins are assigned for the development board that we use in-house.

We use a .tcl script for the students to run before they begin their FPGA designs. The .tcl script has all pin assignment made.

When doing a Full Compile (v18.1 LITE) with the assignments the compile fails because of the earlier mentioned Fitter analysis.

If I then, comment out the pin assignment (see for leds[1] below) and save and run the .tcl file, the FPGA will now have that output pin unassigned. 

Then, like you mentioned, the Fitter will auto-place that output pin to the only available pin left to the FPGA.

BUT this time, the compile will now complete without any error.

Thank you so much.

Charles

[sstrell]

That's great, but any programming files you create will not work with this setup.  leds[1] is now connected to somewhere else on the board, hopefully not something that interferes on your board (like power or ground), so any programming files are useless, unless you rework the boards (connect the LED to the new location) to accommodate the change.

[CKPope]

sorry but the fix works.

Since there is only ONE GPIO pin available after the .tcl file is changed (all pins are assigned except ONE pin), the Fitter does the Auto-placement of that unassigned output to that pin. The compile does complete and the programming file (.sof) downloads and is fully functional.

I am sorry if I misunderstand your comment, but for other designs in general, where there could be more pins available on the FPGA to use for that output, can't those other pins be marked as "Reserved Pins" so that the Fitter can't use them for auto-placement?

[CKPope]

Here is the portion of the Fitter report for the design after employing the work-around change with the .tcl file:

As I mentioned, the compile completes after the auto-placement and the download to the FPGA on our board works as intended.

Thank you everyone for your discussions on this matter.

Charles

[sstrell]

Oh, maybe you are saying that PIN_28 *is* the only pin available.  Now it makes sense.  I thought you meant that there was some other pin available that the Fitter was auto-assigning to.

As for your question about reserved pins, yes, that would work as a workaround for this as well (though of course this bug shouldn't be an issue in the first place).  The fact that a direct assignment doesn't work and doing what you've done does work is silly.