Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attributes are not properly applied to IBUFDS (and possibly other primitives) in Xilinx platform #641

H-S-S-11 opened this issue Oct 9, 2021 · 2 comments


Copy link

H-S-S-11 commented Oct 9, 2021

In the example an IBUFDS resource is created and requested, with particular Attributes:

Resource("IBUFDS", 0,
                DiffPairs("48", "46", conn=("gpio", 1), dir="i"),
                Attrs(IOSTANDARD="LVDS_25", IBUF_LOW_PWR="FALSE")

When run the attributes appear in the generated ucf, and an IBUFDS primitive is instantiated in the generated verilog. However when ISE actually runs synthesis, the instance properties do not show these attributes applied:
In order for ISE to apply the attributes, they need to be parameters to the IBUFDS which is Instanced in

If the generated verilog is edited where the IBUFDS is Instanced, then the attributes are properly applied:

) IBUFDS_0_0 (


Lunaphied added a commit to Lunaphied/amaranth that referenced this issue Dec 13, 2021
ISE doesn't support using the constraints file to specify attributes on
IO buffers, this works around that by specifying them also as module
parameters which ISE does support properly.

Fixes amaranth-lang#641.
Copy link

Are you sure this is issue is actually present?

The IBUF_LOW_PWR attribute, when applied as a parameter to the IBUFDS cell in your design, does not change the bitstream whether its value is "TRUE" or "FALSE", so looking at it is not informative. However, other attributes, like DIFF_TERM or IOSTANDARD, are indeed applied when specified in the UCF file, which you can see by looking at the top_par_pad.txt report.

Copy link

No response from reporter for over two years.

@whitequark whitequark closed this as not planned Won't fix, can't repro, duplicate, stale Feb 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Successfully merging a pull request may close this issue.

2 participants