G
gabor
Guest
On Mar 7, 9:10 am, gabor <ga...@alacron.com> wrote:
I tried ISE 9.2.04i and it does not have this quirk...
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
G
gabor
Guest
I'm trying to figure out if this is a bug in XST or if there
is some logical reason behind it.
I have a design with some inputs that I want to be sure are
inactive until another FPGA is configured. I placed PULLUP
or PULLDOWN components as necessary on them in the
verilog top level module. Immediately two things happened
with XST:
1) I got errors that the inputs were not appropriate for
connection to the PULLUP or PULLDOWN components.
- so I changed them to inout.
2) XST ripped out all the logic using these inputs as
if I had wired them directly to 1 or 0.
Modelsim worked fine with the code including PULLUP or
PULLDOWN.
The final fix was to remove the PULLUP and PULLDOWN from
the source and add it to the .ucf file.
My understanding of the PULLUP/PULLDOWN components is
that it should apply a weak 1 or 0, and in synthesis cause
the actual weak pullup or pulldown to be instantiated in the
IOB if applied to a top level port signal. If not, what is it
supposed
to do for synthesis?
BTW I'm running ISE Foundation 6.1i, I also have the latest
9.2i, but haven't tried this out there yet.
Thanks for any clarification,
Gabor
is some logical reason behind it.
I have a design with some inputs that I want to be sure are
inactive until another FPGA is configured. I placed PULLUP
or PULLDOWN components as necessary on them in the
verilog top level module. Immediately two things happened
with XST:
1) I got errors that the inputs were not appropriate for
connection to the PULLUP or PULLDOWN components.
- so I changed them to inout.
2) XST ripped out all the logic using these inputs as
if I had wired them directly to 1 or 0.
Modelsim worked fine with the code including PULLUP or
PULLDOWN.
The final fix was to remove the PULLUP and PULLDOWN from
the source and add it to the .ucf file.
My understanding of the PULLUP/PULLDOWN components is
that it should apply a weak 1 or 0, and in synthesis cause
the actual weak pullup or pulldown to be instantiated in the
IOB if applied to a top level port signal. If not, what is it
supposed
to do for synthesis?
BTW I'm running ISE Foundation 6.1i, I also have the latest
9.2i, but haven't tried this out there yet.
Thanks for any clarification,
Gabor
J
Jason Zheng
Guest
As a general rule, don't place PULLUP/PULLDOWN in your top-level logic
module, always use ucf or pcd to add those pulls. Placing those pulls
in the logic layer may trick the synthesis tool to start constant
propagation, which is what happened in your case.
These pullup/down constructs in Verilog are meant to used as logical
components. They are for simulation only.
~Jason Zheng
On Fri, 7 Mar 2008 06:10:14 -0800 (PST)
gabor <gabor@alacron.com> wrote:
--
I'd never join any club that would have the likes of me as a member.
-- Groucho Marx
module, always use ucf or pcd to add those pulls. Placing those pulls
in the logic layer may trick the synthesis tool to start constant
propagation, which is what happened in your case.
These pullup/down constructs in Verilog are meant to used as logical
components. They are for simulation only.
~Jason Zheng
On Fri, 7 Mar 2008 06:10:14 -0800 (PST)
gabor <gabor@alacron.com> wrote:
I'm trying to figure out if this is a bug in XST or if there
is some logical reason behind it.
I have a design with some inputs that I want to be sure are
inactive until another FPGA is configured. I placed PULLUP
or PULLDOWN components as necessary on them in the
verilog top level module. Immediately two things happened
with XST:
1) I got errors that the inputs were not appropriate for
connection to the PULLUP or PULLDOWN components.
- so I changed them to inout.
2) XST ripped out all the logic using these inputs as
if I had wired them directly to 1 or 0.
Modelsim worked fine with the code including PULLUP or
PULLDOWN.
The final fix was to remove the PULLUP and PULLDOWN from
the source and add it to the .ucf file.
My understanding of the PULLUP/PULLDOWN components is
that it should apply a weak 1 or 0, and in synthesis cause
the actual weak pullup or pulldown to be instantiated in the
IOB if applied to a top level port signal. If not, what is it
supposed
to do for synthesis?
BTW I'm running ISE Foundation 6.1i, I also have the latest
9.2i, but haven't tried this out there yet.
Thanks for any clarification,
Gabor
--
I'd never join any club that would have the likes of me as a member.
-- Groucho Marx
A
Allan Herriman
Guest
On Fri, 7 Mar 2008 06:10:14 -0800 (PST), gabor <gabor@alacron.com>
wrote:
- XST sees the "inout",
- decides that it needs an output driver,
- doesn't find one in your source,
- so substitutes one of its own, driving a default value.
- The default value will be 1 or 0.
- XST then notices that this pin always has a constant value
- so does "constant propagation" through your code
- which results in most of your code being removed.
Workaround1: remove the "inout" from your code (i.e. change it back
to "in"), and make the pullup another way, perhaps via an attribute in
the source or perhaps via a line in the UCF.
Workaround2: (I'm not sure whether this will work) Keep the pin as an
inout, but this time add a dummy driver which is always held in
tristate. This should stop XST from making its own.
Regards,
Allan
wrote:
I haven't tried it myself, but I speculate thatI'm trying to figure out if this is a bug in XST or if there
is some logical reason behind it.
I have a design with some inputs that I want to be sure are
inactive until another FPGA is configured. I placed PULLUP
or PULLDOWN components as necessary on them in the
verilog top level module. Immediately two things happened
with XST:
1) I got errors that the inputs were not appropriate for
connection to the PULLUP or PULLDOWN components.
- so I changed them to inout.
2) XST ripped out all the logic using these inputs as
if I had wired them directly to 1 or 0.
Modelsim worked fine with the code including PULLUP or
PULLDOWN.
The final fix was to remove the PULLUP and PULLDOWN from
the source and add it to the .ucf file.
My understanding of the PULLUP/PULLDOWN components is
that it should apply a weak 1 or 0, and in synthesis cause
the actual weak pullup or pulldown to be instantiated in the
IOB if applied to a top level port signal. If not, what is it
supposed
to do for synthesis?
BTW I'm running ISE Foundation 6.1i, I also have the latest
9.2i, but haven't tried this out there yet.
- XST sees the "inout",
- decides that it needs an output driver,
- doesn't find one in your source,
- so substitutes one of its own, driving a default value.
- The default value will be 1 or 0.
- XST then notices that this pin always has a constant value
- so does "constant propagation" through your code
- which results in most of your code being removed.
Workaround1: remove the "inout" from your code (i.e. change it back
to "in"), and make the pullup another way, perhaps via an attribute in
the source or perhaps via a line in the UCF.
Workaround2: (I'm not sure whether this will work) Keep the pin as an
inout, but this time add a dummy driver which is always held in
tristate. This should stop XST from making its own.
Regards,
Allan
G
gabor
Guest
On Mar 7, 1:51 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
the inputs as inout doesn't cause the problem if there is no
PULLUP or PULLDOWN on the net.
XST 9.2i does not exhibit this problem, so somewhere between 6.1 and
9.2 Xilinx either "fixed a bug" or "changed their interpretation of
the LRM" depending on how you look at it.
The UCF is in fact the cure to the problem. Although leavingOn Fri, 7 Mar 2008 06:10:14 -0800 (PST), gabor <ga...@alacron.com
wrote:
I'm trying to figure out if this is a bug in XST or if there
is some logical reason behind it.
I have a design with some inputs that I want to be sure are
inactive until another FPGA is configured. I placed PULLUP
or PULLDOWN components as necessary on them in the
verilog top level module. Immediately two things happened
with XST:
1) I got errors that the inputs were not appropriate for
connection to the PULLUP or PULLDOWN components.
- so I changed them to inout.
2) XST ripped out all the logic using these inputs as
if I had wired them directly to 1 or 0.
Modelsim worked fine with the code including PULLUP or
PULLDOWN.
The final fix was to remove the PULLUP and PULLDOWN from
the source and add it to the .ucf file.
My understanding of the PULLUP/PULLDOWN components is
that it should apply a weak 1 or 0, and in synthesis cause
the actual weak pullup or pulldown to be instantiated in the
IOB if applied to a top level port signal. If not, what is it
supposed
to do for synthesis?
BTW I'm running ISE Foundation 6.1i, I also have the latest
9.2i, but haven't tried this out there yet.
I haven't tried it myself, but I speculate that
- XST sees the "inout",
- decides that it needs an output driver,
- doesn't find one in your source,
- so substitutes one of its own, driving a default value.
- The default value will be 1 or 0.
- XST then notices that this pin always has a constant value
- so does "constant propagation" through your code
- which results in most of your code being removed.
Workaround1: remove the "inout" from your code (i.e. change it back
to "in"), and make the pullup another way, perhaps via an attribute in
the source or perhaps via a line in the UCF.
the inputs as inout doesn't cause the problem if there is no
PULLUP or PULLDOWN on the net.
Haven't looked into that, however as I noted in my reply to myself,Workaround2: (I'm not sure whether this will work) Keep the pin as an
inout, but this time add a dummy driver which is always held in
tristate. This should stop XST from making its own.
XST 9.2i does not exhibit this problem, so somewhere between 6.1 and
9.2 Xilinx either "fixed a bug" or "changed their interpretation of
the LRM" depending on how you look at it.
Regards,
Allan
G
gabor
Guest
On Mar 7, 1:08 pm, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
I can see that at least for XST 6.1i this is the case. However the
fact
that PULLUP and PULLDOWN are described in the libraries guide seems to
me to suggest that the synthesis tool should in fact place the
resistor
in the final net. Personally I like to put as much of the design as
possible in the HDL source. The ucf is mostly for implementation
options
rather than functional description.
For example you can define the IOSTANDARD of a pin in the source
or in the UCF file. I like to place it in the source and leave
the UCF to define things like pinout. I was hoping I could do
the same with the PULLUP. As I recall in Synplify for Lattice the
PULLUP/DOWN/KEEP attribute can be attached to the net as an
attribute.
Cheers,
Gabor
As a general rule, don't place PULLUP/PULLDOWN in your top-level logic
module, always use ucf or pcd to add those pulls. Placing those pulls
in the logic layer may trick the synthesis tool to start constant
propagation, which is what happened in your case.
These pullup/down constructs in Verilog are meant to used as logical
components. They are for simulation only.
~Jason Zheng
On Fri, 7 Mar 2008 06:10:14 -0800 (PST)
--
I'd never join any club that would have the likes of me as a member.
-- Groucho Marx
I can see that at least for XST 6.1i this is the case. However the
fact
that PULLUP and PULLDOWN are described in the libraries guide seems to
me to suggest that the synthesis tool should in fact place the
resistor
in the final net. Personally I like to put as much of the design as
possible in the HDL source. The ucf is mostly for implementation
options
rather than functional description.
For example you can define the IOSTANDARD of a pin in the source
or in the UCF file. I like to place it in the source and leave
the UCF to define things like pinout. I was hoping I could do
the same with the PULLUP. As I recall in Synplify for Lattice the
PULLUP/DOWN/KEEP attribute can be attached to the net as an
attribute.
Cheers,
Gabor
S
Stephen Williams
Guest
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
gabor wrote:
a pullup (and/or keeper). xst support Verilog-2001 attributes.
Look in the attributes reference for the actual attribute for a
pullup.
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFH0eGErPt1Sc2b3ikRAqnXAKDFnWkkl09vuKRU8gl5O0JpfETgoQCgvxNX
tsh2T1awbucyKm9+r6i3ApM=
=+Nsq
-----END PGP SIGNATURE-----
Hash: SHA1
gabor wrote:
You should be able to attach and attribute to your port to getPersonally I like to put as much of the design as
possible in the HDL source. The ucf is mostly for implementation
options
rather than functional description.
For example you can define the IOSTANDARD of a pin in the source
or in the UCF file. I like to place it in the source and leave
the UCF to define things like pinout. I was hoping I could do
the same with the PULLUP. As I recall in Synplify for Lattice the
PULLUP/DOWN/KEEP attribute can be attached to the net as an
attribute.
a pullup (and/or keeper). xst support Verilog-2001 attributes.
Look in the attributes reference for the actual attribute for a
pullup.
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFH0eGErPt1Sc2b3ikRAqnXAKDFnWkkl09vuKRU8gl5O0JpfETgoQCgvxNX
tsh2T1awbucyKm9+r6i3ApM=
=+Nsq
-----END PGP SIGNATURE-----
M
Mike Treseler
Guest
gabor wrote:
*device-independent* logic description I put everything else in the
back-end constraint files.
-- Mike Treseler
I use different devices, and prefer to reserve the source code forFor example you can define the IOSTANDARD of a pin in the source
or in the UCF file. I like to place it in the source and leave
the UCF to define things like pinout.
*device-independent* logic description I put everything else in the
back-end constraint files.
-- Mike Treseler