amaranth-lang / amaranth

A modern hardware definition language and toolchain based on Python
https://amaranth-lang.org/docs/amaranth/
BSD 2-Clause "Simplified" License
1.57k stars 174 forks source link

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

Closed alanvgreen closed 4 years ago

alanvgreen commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Will do.

whitequark commented 4 years ago

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.