Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
51 Views

Incomplete pin location assignments

Jump to solution

When a design does not have a complete set of pin location assignments, why does Quartus create a programming file?  If you don't have hardware, you don't need a programming file, and if you do have hardware, the design won't work.  The fact that pins are unassigned is not made very obvious (especially to students just learning about FPGAs).  The best thing to do when using the push button approach is to look for critical warning in the GUI, but most don't, and then waste time looking for the wrong cause of the problem.

I believe Quartus should provide a switch that (by default) turns off programming file generation if any pins in the design are not assigned locations.  

FYI, I wrote a Tcl script to stop compilation after quartus_fit in the push button GUI flow, and it works, but was kind of a pain to write.  I will offer the script to anyone who wants it (unless too many people ask).  Your mileage may vary.....

Xilinx does the same thing, I tried to get them to change the behavior in ISE and then in Vivado as well, they hadn't as of 2017.

Cheers

0 Kudos

Accepted Solutions
Highlighted
Beginner
33 Views

Hi, thanks for the response.  I did want to respond to a couple of things you said, mainly to clarify the discussion.

Certainly there must be pin assignments in order for the complete flow to run, to generate timing information, etc.  In this case it does make sense that Quartus can assign floating pins.  The Quartus assigned pins are guaranteed not to match any board, and generally one would not want to use the pinout for a hardware design, as it will be far from optimal.  

So back to the point, the fitter can generate a random pin assignment to complete a flow, but the corresponding .sof file should not be generated, because it doesn't match any hardware, and should not ever be used.  

Are we on the same page?  All I am saying is that the assembler should not always be run by default, should not be run if the fitter has to assign pins.  Seems like a minor point, but for students learning about digital logic, FPGAs, Quartus, etc., the point isn't so small.

Again, thanks for the feedback.

Cheers.

 

 

View solution in original post

0 Kudos
2 Replies
Highlighted
Retired Employee
38 Views

Your logic is sound except for the fact that there are always pin assignments.  If you don't make location assignments yourself, the Fitter selects locations for you.  You can see the assignments made by the Fitter in the Pin Planner.  Granted, these locations may not match your board, but maybe you'll be designing your board based on the assignments selected by the Fitter.  Then you would back-annotate the Fitter-selected locations to lock them into place for future compilations.

You can turn off the assembler from running during a full compilation to save time (it's either in the Settings dialog or Tools->Options; not sure right now), but it's just on or off.  It isn't based on the status of assignments.

#iwork4intel

0 Kudos
Highlighted
Beginner
34 Views

Hi, thanks for the response.  I did want to respond to a couple of things you said, mainly to clarify the discussion.

Certainly there must be pin assignments in order for the complete flow to run, to generate timing information, etc.  In this case it does make sense that Quartus can assign floating pins.  The Quartus assigned pins are guaranteed not to match any board, and generally one would not want to use the pinout for a hardware design, as it will be far from optimal.  

So back to the point, the fitter can generate a random pin assignment to complete a flow, but the corresponding .sof file should not be generated, because it doesn't match any hardware, and should not ever be used.  

Are we on the same page?  All I am saying is that the assembler should not always be run by default, should not be run if the fitter has to assign pins.  Seems like a minor point, but for students learning about digital logic, FPGAs, Quartus, etc., the point isn't so small.

Again, thanks for the feedback.

Cheers.

 

 

View solution in original post

0 Kudos