Is "Output, Driving Ground" same as out_pin <='0';

[Altera_Forum]

I have a design which uses the unused pins are set to "Output, Driving Ground" setting. 

I thought I would prefer to explicitly set them to ground in the VHDL. I did this and did a compare of the binary output file and it is different???  Is there one of the numerous Altera tools which will show me the detail of how the IO is programmed?  Thanks   Steve

[Altera_Forum]

If you reserve an unused pin as "As output driving ground", the .pin file and Fitter report "All Package Pins" table will list that pin as "GND*". The top of the .pin file says the GND* pins may be connected to ground on the board or left unconnected. 

 I don't know of another place where you can see that the pin is programmed as a hard zero. When I tried the Chip Planner for that so that I could locate from there to the Resource Property Editor, I wasn't able to do it for an unused pin.

[Altera_Forum]

I did a test using tabular text files (.ttf) for a Cyclone III device. I back annotated a fit result so that the only difference would be how I handled an unused pin. 

 When I used  set_instance_assignment -name RESERVE_PIN "AS OUTPUT DRIVING GROUND" -to unused_output  I got exactly the same .ttf file as when I drove the pin unused_output with a low in the source file.  If you did not back annotate the fit for the first thing you tried, the change to the source file when you changed between having the pin there and using a reserve-pin setting might have had the effect of a different seed for the Fitter, changing the placement and routing.

[Altera_Forum]

You're right. I haven't been back-annotating. 

When I tried to back-annotate, it recommended writing vqm file instead. I tried the vqm route and I tried the back-annotate route. With my EP1C6 design it seems to generate different files a lot! Even just back-annotating and then recompiling with no other changes, the rbf/ttf output files are different!  I think I will explicity drive these outputs to ground from within the VHDL. I would prefer my unused pins default to input with weak pullup. (safer default!) Hopefully the IO is just "as good a ground" with this approach. I can't see any reason they wouldn't use the same transistor for both data and SSN grounding functions ... unless the SSN transistor is bigger/slower/lowerRDSon ... hmmm  Oh well. If anyone knows ... I'm listening.   Thanks   Steve

[Altera_Forum]

I think I made a mistake in my Cyclone III test case (I'd already deleted some files before I could confirm that), but hopefully my EP1C6 test case in unused_pin_test_case.zip is correct. I still had no difference in .ttf files for the unused pin reserved as output driving ground versus hardwired to zero in the source file. 

 I used a very simple test case for which the back annotation works without a .vqm to keep the node names matching those in the location settings. I have no combinational nodes in the test case. For a real design that includes combinational node names that can change from one compile to the next, a .vqm will reduce the chance of a name change but not prevent it (the .vqm has to be run back through Analysis & Synthesis for the next compile). Even register names can change between compiles if synthesis is creating instance names inside megafunctions (megafunctions often have a suffix like a serial number on the instance names created during synthesis).  You have to back annotate routing in addition to placement to make sure the routing is identical in the two programming files you compare. Node name changes make parts of the routing back annotation not work.  It can be difficult to preserve everything exactly with back annotation in a real design. If you really needed to back annotate something, incremental compilation would be the better way to do it.  In your case though, back annotation isn't the point of what you want to accomplish. You just need confidence that two ways of handling an unused pin produce exactly the same programming file. To reassure yourself of that, a test like the one I did using a trivial little design for which back annotation with routing will work avoids the complications of trying to check what you care about using the real design. With the simple test case, it's easier to make sure that the two different methods of handling the unused pin are the only difference in the two compilations for which you are comparing programming files.

[Altera_Forum]

Wow. I didn't know you could do those things with quartus! 

Having multiple versions "running" side by side is an interesting feature.  I am a little confused at what you've proven though!  When I compile the version that drives the ground and the version that doesn't and I have the default unused pin as weak pullup, I would expect a difference in the ttf, but it matches?? In fact I think this is the way you sent it in the zip. So I would have expected E2 to be grounded in one ttf, but weakly pulled up in the other.  Is something broken, or am I missing something?   Steve

[Altera_Forum]

--- Quote Start ---  I am a little confused at what you've proven though!  When I compile the version that drives the ground and the version that doesn't and I have the default unused pin as weak pullup, I would expect a difference in the ttf, but it matches?? In fact I think this is the way you sent it in the zip. So I would have expected E2 to be grounded in one ttf, but weakly pulled up in the other.  --- Quote End ---    unused_pin_as_output_driving_ground.ttf and unused_pin_grounded_in_source_file.ttf are identical.  If I didn't make a mistake, that proves that driving an output pin with a hard-wired low in the source file produces exactly the same programming file as using the following .qsf setting. That was the whole point of my exercise. That means that when your programming files were different in your original post, it was because something else--probably in placement and routing--was different for those two compiles.    --- Quote Start ---  set_instance_assignment -name RESERVE_PIN "AS OUTPUT DRIVING GROUND" -to unused_pin  --- Quote End ---    unused_pin_as_output_driving_ground.ttf and unused_pin_as_input_tristated.ttf are different.  I included the unused_pin_as_input_tristated.qsf revision with the next .qsf line below just so that I would have an expected .ttf difference to give me a little more confidence that the match of the other two .ttf files was a valid test.    --- Quote Start ---  set_instance_assignment -name RESERVE_PIN "AS INPUT TRI-STATED" -to unused_pin  --- Quote End ---    The following .qsf line was the same for all three revisions. The following line applies only to pins that are neither in the source file nor in RESERVE_PIN settings. This line did not apply to the single unused pin that I was controlling by grounding it in the source file or by using a RESERVE_PIN setting. The RESERVE_ALL_UNUSED_PINS line made no difference in the three .ttf files--I just had to have some setting for the rest of the unused pins.    --- Quote Start ---  set_global_assignment -name RESERVE_ALL_UNUSED_PINS "AS INPUT TRI-STATED WITH WEAK PULL-UP"  --- Quote End ---      --- Quote Start ---  Having multiple versions "running" side by side is an interesting feature.  --- Quote End ---    You compile only one revision at a time. To compile each revision, select the revision first with "Project --> Revisions".  The main uses of revisions are to evolve your .qsf settings while not losing the results of each setting combination you try or to have .qsf files with different settings for different purposes or for comparison as I did here. The Quartus revision feature does not include source file revisions, so I had to create two separate source files with and without the unused pin grounded within the source file and have each Quartus revision (each .qsf) reference the correct source file. That's where I think I made a mistake in my Cyclone III test, but I tried to be more careful for the attached test case.

[Altera_Forum]

Thanks I think I understand now. 

 I just started using Quartus in July ... my previous Altera design was a 10K10 in MaxPlusII! This new software is VERY sophisticated, and it looks like you need to leave the gui behind to realize it's true power.  I had used the gui to do this: set_global_assignment -name RESERVE_ALL_UNUSED_PINS "AS INPUT TRI-STATED WITH WEAK PULL-UP"  But never even realized this was possible: set_location_assignment PIN_E2 -to unused_pin set_instance_assignment -name RESERVE_PIN "AS OUTPUT DRIVING GROUND" -to unused_pin  Is there a good reference for the qsf file contents? So far I've been learning by observing what the gui does in there.  BTW: Are you an Altera employee, or just trying to become one:)  Thanks again   Steve

[Altera_Forum]

I almost exclusively use the GUI. I rarely edit the .qsf directly, but there is complete support for working from the command line and creating the .qsf settings with a script. 

 The .qsf lines came from assignments I made in the Assignment Editor, placing pins manually in the Pin Planner, the project-wide setting at "Assignments --> Device --> Device and Pin Options --> Unused Pins", and the back annotation. Since I was going to back annotate everything anyway, it didn't matter whether I placed the pins myself, but I did have to create the reserved pin when I didn't have this unused pin grounded in the source file.  There is a manual for QSF settings in the Quartus literature area of the Altera web site. I think it has the same information as on-line help.