Unused Pin setting on per-pin basis

Hi all,

I've got a custom FPGA board with a number of peripherals connected to
the FPGA. I need to keep the connections between the FPGA and unused
peripherals in a sensible state.

Is there a way I can define FPGA pins as inputs with different
pull-up/pull-down/floating states without including dummy signals in my HDL.

bitgen offers the option to set ALL unused pins to
pull-up/pull-down/floating, but I need to set this on a per/pin basis.

Any ideas anyone?

Thanks
Andy

On 2 Mai, 10:11, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Hi all,
>
> I've got a custom FPGA board with a number of peripherals connected to
> the FPGA. I need to keep the connections between the FPGA and unused
> peripherals in a sensible state.
>
> Is there a way I can define FPGA pins as inputs with different
> pull-up/pull-down/floating states without including dummy signals in my HDL.
>
> bitgen offers the option to set ALL unused pins to
> pull-up/pull-down/floating, but I need to set this on a per/pin basis.
>
> Any ideas anyone?
>
> Thanks
> Andy

no
ASFAIK
its sometimes really annoying..:(

Antti

On 2 Mai, 10:11, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:

> bitgen offers the option to set ALL unused pins to
> pull-up/pull-down/floating, but I need to set this on a per/pin basis.

What do you need the per pin configuration for? The pullups are
extremely
week. (5uA to 200uA for Virtex-4). I can't imagine a digital
application that
will be disturbed by that.

If you really need it you good create a pre placed hard macro in FPGA
editor
including the pads and instantiate that as a black box.
I think you can even instantiate IO with placement constraints in HDL
without
bringing the signals out to toplevel. But I never tried that.

Kolja Sulimma

comp.arch.fpga wrote:
 > What do you need the per pin configuration for? The pullups are
> extremely
> week. (5uA to 200uA for Virtex-4). I can't imagine a digital
> application that
> will be disturbed by that.

The board uses a with a Spartan-3E. The data sheet suggest the pull down
is 34K5 (Table 77 - ds312). I guess that's not too strong.

However, I'd prefer the option to control the pull resistors on a
per-pin basis. It just seems to me a 'better' way of doing things.

Thanks for the suggestions
Andy

On May 2, 5:15 am, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> comp.arch.fpga wrote:
>
>  > What do you need the per pin configuration for? The pullups are
>
> > extremely
> > week. (5uA to 200uA for Virtex-4). I can't imagine a digital
> > application that
> > will be disturbed by that.
>
> The board uses a with a Spartan-3E. The data sheet suggest the pull down
> is 34K5 (Table 77 - ds312). I guess that's not too strong.
>
> However, I'd prefer the option to control the pull resistors on a
> per-pin basis. It just seems to me a 'better' way of doing things.
>
> Thanks for the suggestions
> Andy


If you really want pullups or pulldowns and not to actively drive the
pins, the tool chain will remove your instantiated pullups/pulldowns
unless it determines the inputs to be used.  However you can change
the IOB parameters in the FPGA editor after you build the design.
I haven't tried it myself, but there is a way to create a command file
for the FPGA editor to make the same changes in a subsequent
build.

HTH,
Gabor

On May 2, 4:15 am, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> comp.arch.fpga wrote:
>
>  > What do you need the per pin configuration for? The pullups are
>
> > extremely
> > week. (5uA to 200uA for Virtex-4). I can't imagine a digital
> > application that
> > will be disturbed by that.
>
> The board uses a with a Spartan-3E. The data sheet suggest the pull down
> is 34K5 (Table 77 - ds312). I guess that's not too strong.
>
> However, I'd prefer the option to control the pull resistors on a
> per-pin basis. It just seems to me a 'better' way of doing things.
>
> Thanks for the suggestions
> Andy

You should be able to alter the UCF to add the pull-up / pull-downs,
though the resistor is permanently enabled after configuration. (you
can't control it from the fabric) You can use this feature to
eliminate external resistors with great effect.  For example, I have a
small add-in board that doesn't supply a proper VCC, so I use the
internal pull-up to keep the reset line high, and use a switch to
short the circuit to ground. Perhaps not the safest circuit, but it
works.

Of course, if the peripheral really is unused, and you just want to
keep the device in a low-power/safe state, why not just drive the I/O
directly from the VHDL? For example, right now I'm using a ComBlock
board that has no free-running oscillator connected to the FPGA.
Instead, you have to get your clock from the USB PHY, which only
produces said clock after you drive its SUSPENDN signal high. (Of
course this signal is pulled low, so your firmware has to pull it
high, then hold the DCMs in reset until the output clock is stable...)
I just have a line in the VHDL that directly drives that signal high.

On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote:
> You should be able to alter the UCF to add the pull-up / pull-downs,
> though the resistor is permanently enabled after configuration. (you
> can't control it from the fabric) You can use this feature to
> eliminate external resistors with great effect.  For example, I have a
> small add-in board that doesn't supply a proper VCC, so I use the
> internal pull-up to keep the reset line high, and use a switch to
> short the circuit to ground. Perhaps not the safest circuit, but it
> works.

Again the UCF method only works if the pin in question has
a net attached to it, i.e. if it doesn't get removed from the
project as unused.  I don't know of any method in the UCF
to refer to pins merely by location.  So while you can put a
line in the UCF like
NET "Foo" LOC = AA12 | PULLUP ;
as soon as the net Foo gets removed from the project
the pullup resistor goes away, too.

On May 3, 12:28 pm, Gabor <g...@alacron.com> wrote:
> On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote:
>
> > You should be able to alter the UCF to add the pull-up / pull-downs,
> > though the resistor is permanently enabled after configuration. (you
> > can't control it from the fabric) You can use this feature to
> > eliminate external resistors with great effect.  For example, I have a
> > small add-in board that doesn't supply a proper VCC, so I use the
> > internal pull-up to keep the reset line high, and use a switch to
> > short the circuit to ground. Perhaps not the safest circuit, but it
> > works.
>
> Again the UCF method only works if the pin in question has
> a net attached to it, i.e. if it doesn't get removed from the
> project as unused.  I don't know of any method in the UCF
> to refer to pins merely by location.  So while you can put a
> line in the UCF like
> NET "Foo" LOC = AA12 | PULLUP ;
> as soon as the net Foo gets removed from the project
> the pullup resistor goes away, too.

If the pin really is unused, and you really want that pin to float or
stay at a DC level, then just add the appropriate net. Even something
simple like dummy_net <= 'Z'; would cover it. Just check the FPGA
editor to make sure you are really getting a permanently disabled tri-
state buffer. Then, add the pullup/pulldown constraint to the UCF. Is
there a reason you can't add a dummy net to the pin?

I generally make a practice of assigning nets to all external I/O, and
then tie them off in the top-level until they are used - just so I can
control stuff like this. That way, I can finish the I/O constraints
early on, and not have to worry about mucking with them later on.

On May 3, 2:19 pm, radarman <jsham...@gmail.com> wrote:
> On May 3, 12:28 pm, Gabor <g...@alacron.com> wrote:
>
>
>
> > On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote:
>
> > > You should be able to alter the UCF to add the pull-up / pull-downs,
> > > though the resistor is permanently enabled after configuration. (you
> > > can't control it from the fabric) You can use this feature to
> > > eliminate external resistors with great effect.  For example, I have a
> > > small add-in board that doesn't supply a proper VCC, so I use the
> > > internal pull-up to keep the reset line high, and use a switch to
> > > short the circuit to ground. Perhaps not the safest circuit, but it
> > > works.
>
> > Again the UCF method only works if the pin in question has
> > a net attached to it, i.e. if it doesn't get removed from the
> > project as unused.  I don't know of any method in the UCF
> > to refer to pins merely by location.  So while you can put a
> > line in the UCF like
> > NET "Foo" LOC = AA12 | PULLUP ;
> > as soon as the net Foo gets removed from the project
> > the pullup resistor goes away, too.
>
> If the pin really is unused, and you really want that pin to float or
> stay at a DC level, then just add the appropriate net. Even something
> simple like dummy_net <= 'Z'; would cover it. Just check the FPGA
> editor to make sure you are really getting a permanently disabled tri-
> state buffer. Then, add the pullup/pulldown constraint to the UCF. Is
> there a reason you can't add a dummy net to the pin?
>
> I generally make a practice of assigning nets to all external I/O, and
> then tie them off in the top-level until they are used - just so I can
> control stuff like this. That way, I can finish the I/O constraints
> early on, and not have to worry about mucking with them later on.


In my experience (using XST) if I assign Z to a pad, the net is
stripped from
the design and then anything attached to the net in the UCF file goes
away, too.  How do you keep your "dummy_net" from being
removed?

Gabor <gabor@alacron.com> writes:

>
> In my experience (using XST) if I assign Z to a pad, the net is
> stripped from
> the design and then anything attached to the net in the UCF file goes
> away, too.  How do you keep your "dummy_net" from being
> removed?
>

Can you instantiate OBUFTs and wire the tristate input to an input pin
that you know is static GND (or VCC via an inverter)?

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html