Problem with unused pin on Spartan 2E

That is a common expectation, but the usual default for unused FPGA pins is low impedance drive to power or ground, for lower noise, or even to a random internal node to save a route. This will vary by device and sometimes by software revision.

That works, but I prefer to declare the unused pin drive explicitly in the place and route settings file to keep the source code clean and easy to sim.

There are almost always other device constraints like pin numbers that don't really belong in the source code either. When a design is final, I like to tie the remaining unused IOs to ground.

-- Mike Treseler

My guess is that the two designs were run with different versions of the synthesis/place & route software. The earlier version of the software defaulted unused I/O pins to be tri-state; the newer version actively drives them. Solutions are:

- Use the older software for the new design. This is not necessarily a 'good' idea to be using out of date software which is less likely to be supported).

- Define the 'unused' pins as explicit inputs as you've done to come up with something that works. While this is a workable solution you're gumming up the design a bit by defining pins as input signals that you have no intention of using...which is probably making you feel a bit leary about this approach (as it should). It does work though.

- Find the setting that you need that sets unused I/O pins to tri-state (if such an option is available in whatever version you happen to be using). This would usually be the 'best' approach since used be using fully supported software and you're not adding artificial tweaks just to please the tool. Usually the only trouble comes in when you want some of those 'unused' pins to really be a high and others to be low for some reason. If that's the situation though then whatever process tha was followed that got the PCBA design into this type of situation needs to be reviewed since it is clearly not acceptable to have two different pins that 'should' be no connects tied to different voltages. If this is the case, then you're kind of stuck with the previous bullet about explicitly defining the pins as inputs as you've done.

Not necessarily. Actively driving an 'unused' pin tends to decrease simultaneous switching noise for the actively used outputs of the FPGA so from the perspective of the part itself it would rather not have these open or weakly driven. As parts get faster and faster over time this becomes more of an issue to keep in mind.

Kevin Jennings

To all who answered: I USED THE EXACT SAME VERSION FOR BOTH REVS - ISE V6.3

Thanks

Something was different.

-- Mike Treseler

If you connect an 'unused' pin to a backplane (always driven by other devices) then the safest thing to do, is declare that pin as an input - even if it means some dummy code to keep the tool flows happy.

Some Sw has default 'unused to GND' / Unused to Pinkeep / Unused to Pullups' options, but certainly the tools _SHOULD_ correctly report what they finally did.

I'd be miffed if a tool chain committed an unsed pin, without explaining that it had done so.

-jg

It sounds like that pin isn't actually a no-connect, but is used since you are expecting a particular behavoiour. As one poster mentioned (and increased my knowledge) the tools will do whatever they want with a pin that it figures are unconnected. If you have a specific behaviour you need, you need to tell it so. Sounds like you lucked out in a manner of sorts that it drove the pin to the same logic state of the other driver on that net in previous builds.

Mounard Le Fougueux wrote:

my guess is that it decided to use that "unused" IOB for some internal routing purposes to meet explicit constraints.

I am now using the FPGA editor (post route) to verify that fact.

Inthe xilinx 6.3.3 tools, there is an option for unused pins under Configuration properies, but I belive that only applies to configuration pins, such as JTAG or M0 -M2 pins only.

I didn't watch the thread early on so I reviewed it before posting. You didn't mention the package and associated pin number. It could be that this is a "dual purpose" pin that might have a separate configuration bit in bitgen that controls whether it's a user IO after configuration or continues to be driven. The Done/Busy line was a problem for one engineer on a recent thread where the pin became a user-IO too early. If your bitgen setup somehow changed to allow a dedicated pin to maintain its function, that could be what's causing the problems.

If FPGA Editor comes up with an unused I/O, please look at whether the pin is dual-purpose. There were problems many, many years back even with the VREF pins during power-up when VREF wasn't even used on the bank; those problems should be long gone but sometimes other glitches show up to remind us who we are.

- John_H