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

Unassigned signals do not assume their reset values #35

Closed
jfng opened this issue Feb 5, 2019 · 1 comment
Closed

Unassigned signals do not assume their reset values #35

jfng opened this issue Feb 5, 2019 · 1 comment

Comments

@jfng
Copy link
Contributor

jfng commented Feb 5, 2019

Leaving a Signal unassigned does not make it assume its reset value when used as the RHS of an assignment.

Consider the following snippet:

from nmigen import *
from nmigen.back import rtlil


class Foo:
    def elaborate(self, platform):
        m = Module()

        foo = Signal(reset=1)
        bar = Signal()
        m.d.comb += bar.eq(foo)

        return m


foo = Foo()
frag = foo.elaborate(platform=None)
print(rtlil.convert(frag))

which produces the following IR:

attribute \generator "nMigen"
attribute \top 1
module \top
  attribute \src "foo.py:9"
  wire width 1 input 0 \foo
  attribute \src "foo.py:10"
  wire width 1 \bar
  attribute \src "foo.py:10"
  wire width 1 $next\bar
  process $group_0
    assign $next\bar 1'0
    assign $next\bar \foo
    sync init
    sync always
      update \bar $next\bar
  end
end

Should \foo be set to its reset value instead of being propagated as an input ?

@whitequark
Copy link
Contributor

Duplicate of #30.

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

No branches or pull requests

2 participants