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

write_verilog: do not print (*init*) attributes on regs #1393

Merged
merged 1 commit into from
Oct 27, 2019

Conversation

whitequark
Copy link
Member

@whitequark whitequark commented Sep 22, 2019

If an init value is emitted for a reg, an (*init*) attribute is never
necessary, since it is exactly equivalent. On the other hand, some
tools that consume Verilog (ISE, Vivado, Quartus) complain about
(*init*) attributes because their interpretation differs from Yosys.

All (*init*) attributes that would not become reg init values anyway
are emitted as before.

If an init value is emitted for a reg, an (*init*) attribute is never
necessary, since it is exactly equivalent. On the other hand, some
tools that consume Verilog (ISE, Vivado, Quartus) complain about
(*init*) attributes because their interpretation differs from Yosys.

All (*init*) attributes that would not become reg init values anyway
are emitted as before.
@whitequark
Copy link
Member Author

Can we backport this to a release branch? Not being able to use nMigen/Yosys with proprietary toolchains for a year is pretty annoying. There is no workaround (using attrmap would prevent both forms of initialization from being emitted) other than somehing like patching the Verilog output with a regexp.

@whitequark
Copy link
Member Author

@cliffordwolf @eddiehung Are there any objections to the change itself, regardless of whether it goes to a release branch?

@eddiehung
Copy link
Collaborator

@cliffordwolf @eddiehung Are there any objections to the change itself, regardless of whether it goes to a release branch?

I haven't looked at this in detail, but I recall that @cliffordwolf expressed some concerns about whether there were any obscure corner cases that could be affected, and that he's still intent on reviewing it properly ... Hope that helps!

@whitequark
Copy link
Member Author

Thanks, that's fine with me. I was worried it fell through the cracks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants