Xilinx XST synthesis removes input pin even though it's LOCe

M

Matt Dykes

Guest
XST keeps removing some of my input pins. I have used the LOC
attribute in both the VHDL itself and in the .ucf file to no avail.
After PAR, the pins declared in the port declaration (and LOCed to
specific pins) have not been routed to a pad.

The inputs ARE used by latching into a register that is later read.
Any thoughts on why XST is removing them and how to make it stop?
Thx-Matt
 
Synthesisers usually remove unused inputs. One crude way that works with all
synthesiser is to use the unused inputs in a dummy function. This dummy
function must be used somewhere but if you make it so that is always '1' or
'0' and use that value where you don't care then that will be enough. If you
have a spare pin you can always attached the function to that.

A typical dummy function might be an OR gate of all unused signals possibly
with some real signals as well to ensure a always '1' output.
Similarly use AND gate for '0'.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.

"Matt Dykes" <mattdykes@earthlink.net> wrote in message
news:8a89c2c3.0406171251.42e240ca@posting.google.com...
XST keeps removing some of my input pins. I have used the LOC
attribute in both the VHDL itself and in the .ucf file to no avail.
After PAR, the pins declared in the port declaration (and LOCed to
specific pins) have not been routed to a pad.

The inputs ARE used by latching into a register that is later read.
Any thoughts on why XST is removing them and how to make it stop?
Thx-Matt
Click to expand...
 
"Matt Dykes" <mattdykes@earthlink.net> wrote in message
news:8a89c2c3.0406171251.42e240ca@posting.google.com...
XST keeps removing some of my input pins. I have used the LOC
attribute in both the VHDL itself and in the .ucf file to no avail.
After PAR, the pins declared in the port declaration (and LOCed to
specific pins) have not been routed to a pad.

The inputs ARE used by latching into a register that is later read.
Any thoughts on why XST is removing them and how to make it stop?
Thx-Matt
Click to expand...
Hi,

Have a look at the SAVE NET FLAG constraint in the cgd.pdf documentation.

Regards,
Alvin.
 
Have a look at the SAVE NET FLAG constraint in the cgd.pdf documentation.
Click to expand...
http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/cgd/cgd.pdf
 
Frank Benoit <nospam@xyz.com> wrote in message news:<pan.2004.06.19.20.15.14.179200@xyz.com>...
Have a look at the SAVE NET FLAG constraint in the cgd.pdf documentation.

http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/cgd/cgd.pdf
Click to expand...
Using LOC and SAVE NET FLAG with no results. The PARer gives the
warnings:
"logical net on "signal" has no load" and
"Attribute LOC on "signal" is on the wrong type of object."

Then looking at the project.pad_txt file, "signal" does not show up.

I thought about using the dummy function, but the inputs are just
discrete interrupts from outside that update a register that gets
read/reset at some later time. What better 'dummy' funtion? I can
see how it could get optimized out, but those inputs are needed
whether XST thinks they are or not.

Reading the docs leads me to believe the SAVE NET FLAG should do the
job, but..... Thanks again for the suggestions. Knowing where to
find that doc is worth the post!
 
I would check that the register isn't being removed. A synthesiser will tend
to remove anything that it thinks unused or unconnected.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.
"Matt Dykes" <mattdykes@earthlink.net> wrote in message
news:8a89c2c3.0406210453.5fd2323@posting.google.com...
Frank Benoit <nospam@xyz.com> wrote in message
news:<pan.2004.06.19.20.15.14.179200@xyz.com>...
Have a look at the SAVE NET FLAG constraint in the cgd.pdf
documentation.

http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/cgd/cgd.pdf

Using LOC and SAVE NET FLAG with no results. The PARer gives the
warnings:
"logical net on "signal" has no load" and
"Attribute LOC on "signal" is on the wrong type of object."

Then looking at the project.pad_txt file, "signal" does not show up.

I thought about using the dummy function, but the inputs are just
discrete interrupts from outside that update a register that gets
read/reset at some later time. What better 'dummy' funtion? I can
see how it could get optimized out, but those inputs are needed
whether XST thinks they are or not.

Reading the docs leads me to believe the SAVE NET FLAG should do the
job, but..... Thanks again for the suggestions. Knowing where to
find that doc is worth the post!
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top