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

Jump to bottom

_yosys fails to parse Yosys version from fomu-toolchain #409

Closed
alanvgreen opened this issue Jun 22, 2020 · 3 comments
Closed

_yosys fails to parse Yosys version from fomu-toolchain #409

alanvgreen opened this issue Jun 22, 2020 · 3 comments
Labels
improvement
Milestone
0.3

Comments

@alanvgreen
Copy link
Contributor

I have been yosys and nextpnr-ice40 from v1.5.6 of the fomu-toolchain, downloaded from https://github.com/im-tomu/fomu-toolchain/releases/tag/v1.5.6

The version number reported by the fomu-toolchain build of yosys is not compatible with the version number parser in _yosys.py. Here is the traceback from calling platform.build():

Traceback (most recent call last):
  File "./video.py", line 203, in <module>
    buildAndRunTest(DEMOS[args.demo], RESOLUTIONS[args.resolution], args.seed, args.optimize, args.program)
  File "./video.py", line 176, in buildAndRunTest
    platform.build(demo(resolution),
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/build/plat.py", line 90, in build
    plan = self.prepare(elaboratable, name, **kwargs)
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/build/plat.py", line 163, in prepare
    return self.toolchain_prepare(fragment, name, **kwargs)
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/build/plat.py", line 437, in toolchain_prepare
    render(content_tpl, origin=content_tpl))
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/build/plat.py", line 419, in render
    return compiled.render({
  File "/home/osboxes/ib/lib/python3.8/site-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/home/osboxes/ib/lib/python3.8/site-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
  File "/home/osboxes/ib/lib/python3.8/site-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 2, in top-level template code
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/build/plat.py", line 314, in emit_debug_verilog
    return verilog._convert_rtlil_text(rtlil_text,
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/back/verilog.py", line 10, in _convert_rtlil_text
    yosys = find_yosys(lambda ver: ver >= (0, 9))
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/_yosys.py", line 211, in find_yosys
    if proxy.available() and requirement(proxy.version()):
  File "/home/osboxes/ib/lib/python3.8/site-packages/nmigen/_yosys.py", line 154, in version
    return (int(match[1]), int(match[2]), int(match[3] or 0))
TypeError: 'NoneType' object is not subscriptable

The above message is due to match being None, since the regex match failed.

Here is the yosys version string from the fomu build of yosys:

$ yosys -V
Yosys 7f5c73d58fd732a96e480083896cd73c722849ba (Fomu build) (git sha1 66613d5, gcc 7.4.0-1ubuntu1~18.04.1 -fPIC -Os)

Here are a couple of possible solutions:

  1. nMigen could reject unversioned yosys binaries and fallback to nmigen-yosys, if available.
  2. nMigen could accept unversioned yosys binaries, but with a warning
  3. request fomu-toolchain to build yosys binaries so that they report a version number that is parsable by nMigen
  4. nMigen could be left incompatible with fomu-toolchain

Of these, think 1 is best. I'm happy to try making a PR for either 1 or 2.
@whitequark
Copy link
Member

It is not possible to do option 2, since the output of nMigen has to be customized for the Yosys version it works with (RTLIL is not stable); so option 1 seems sensible.

@alanvgreen
Copy link
Contributor Author

Will do.

@whitequark
Copy link
Member

I would be fine with (3) but I think we should do (1) in parallel, since this is probably not the last time we encounter such Yosys builds.

alanvgreen added a commit to alanvgreen/nmigen that referenced this issue Jun 23, 2020
@alanvgreen
_yosys.py: handle unparseable versions
73dfbd7 
Do not use versions of yosys with unparseable version numbers. This
ensures that nmigen always knows what verion of yosys it is generating
RTLIL for.

Issue amaranth-lang#409.
alanvgreen added a commit to alanvgreen/nmigen that referenced this issue Jun 23, 2020
@alanvgreen
_yosys.py: handle unparseable versions
cdbffaa 
Do not use yosys binaries with unparseable version numbers. This ensures
that nmigen always knows what version of yosys it is generating RTLIL
for.

The effect of this change is that if the version number of the system
yosys is unparsable, nmigen will attempt to fallback to the builtin
Yosys.

Issue amaranth-lang#409.
alanvgreen added a commit to alanvgreen/nmigen that referenced this issue Jun 23, 2020
@alanvgreen
_yosys.py: handle unparseable versions
05d10d4 
Do not use yosys binaries with unparseable version numbers. This ensures
that nmigen always knows what version of yosys it is generating RTLIL
for.

The effect of this change is that if the version number of the system
yosys is unparsable, nmigen will attempt to fallback to the builtin
Yosys.

Issue amaranth-lang#409.
@alanvgreen alanvgreen mentioned this issue Jun 23, 2020
Merged
@whitequark whitequark added this to the 0.3 milestone Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
improvement
Milestone
0.3
Development

No branches or pull requests
2 participants
@whitequark @alanvgreen