You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
At the moment, Yosys is a hard dependency of nMigen if back.verilog is used. Because of the debug Verilog output provided even in FOSS design flows (where the synthesis ingests RTLIL, not Verilog), nearly any practical use of nMigen beyond simulation via back.pysim requires Yosys to be installed.
Although not catastrophic (Yosys is a relatively easy to build C++ codebase), this can be a significant obstacle for beginners. Further, this forces nMigen to support a wide range of Yosys revisions (from latest stable to master, which currently spans over 4000 commits), ties nMigen to the irregular, approximately once per year Yosys release schedule, and requires Yosys-dependent transformations to gracefully degrade if they find themselves used with an outdated version.
In concrete terms, even after #324 is fixed, when is back.cxxsim "shipped"? Is it when Yosys 0.10 is released? (What if we miss the window for that and have to wait a year more for 0.11?) Is it when Yosys 0.10 is in Debian testing? Debian stable? some third party PPA? What happens if, shortly after the Yosys release, a functionality-breaking bug is discovered in the CXXRTL backend?
Morally, Yosys-as-part-of-back.verilog should not be a system dependency, but rather a part of nMigen itself. However, achieving that is not trivial.
The text was updated successfully, but these errors were encountered:
The package seems to work well on Linux and Windows. (Shouldn't have issues on macOS either, but I didn't check.)
The startup latency is acceptable, even in a VM.
The package is quite small: the compressed size is less than 500 KB, and the installed size is less than 2 MB, not including wasmtime.
By defining nmigen_yosys.__main__ it is possible to make /usr/bin/python3 -m nmigen_yosys a drop-in replacement for /usr/bin/yosys as long as no absolute paths are used. (nMigen doesn't use them anywhere, and further, avoids invoking Yosys with any paths at all.)
Wasmtime-py doesn't currently cache compiled machine code, and recompiling yosys.wasm is the majority of time spent in back.verilog on small and medium size designs.
The startup latency (especially given the previous downside) and package size are acceptable only because I've committed some crimes. Yosys does not allow choosing an arbitrary set of passes to be built (in fact it does not even track pass dependencies), and the SMALL:=1 binaries are not so small (about 10 MB stripped), so it is necessary to override the list of targets that go into the final executable.
WASI is not yet upstream in Yosys.
Overall, this solution seems acceptable; the main problem is the lack of 32-bit Windows wheels in wasmtime. By using python3 -m nmigen_yosys as a drop-in replacement, the Yosys packaging strategy can be changed to anything else at a later date, so the risks of going with WASI are low; worst case, we just have to go back to building win32 and anylinux wheels.