Add WASI platform support

[whitequark]

See PR #1483 for a previous attempt (for some reason I can't reopen that PR).

---

This PR includes the following significant changes:

• Patching ezsat and minisat to disable resource limiting code on WASM/WASI, since the POSIX functions they use are unavailable.
• Adding a new definition, YOSYS_DISABLE_SPAWN, present if platform does not support spawning subprocesses (i.e. Emscripten or WASI). This definition hides the definition of run_command().
• Adding a new Makefile flag, DISABLE_SPAWN, present in the same condition. This flag disables all passes that require spawning subprocesses for their function. It replaces ad-hoc checks of $(CONFIG).

---

This PR cannot be merged yet. Unresolved issues:

• abc: use YosysHQ/abc instead of upstream berkeley-abc/abc #1946 required for merging PR
• Make use of setrlimit conditional on ABC_NO_RLIMIT abc#2 required for ENABLE_ABC:=1 build
• Allow changing the ar binary abc#3 required for ENABLE_ABC:=1 build
• Add more WASI conditional compilation abc#5 required for ENABLE_ABC:=1 build
• What, if anything, do we do about C++ exceptions?

---

In practice, WASI Yosys works quite well. I can synthesize medium sized iCE40 designs with the linked ABC just fine, and in reasonable time as well (within an order of magnitude even without LTO). Compiling Yosys itself from WASM to native code can take quite a while in the maximal configuration, but, fortunately, the native code is easily cached.

I am using WASI SDK, wasmtime, patched abc, and the following Yosys configuration:

CONFIG := wasi

WASI_SDK := $(CURDIR)/wasi-sdk-10.0

ENABLE_TCL := 0
ENABLE_ABC := 1
ENABLE_GLOB := 0
ENABLE_PLUGINS := 0
ENABLE_READLINE := 0
ENABLE_EDITLINE := 0
ENABLE_VERIFIC := 0
ENABLE_COVER := 0
ENABLE_LIBYOSYS := 0
ENABLE_PROTOBUF := 0
ENABLE_ZLIB := 0

SMALL := 0

CXXFLAGS += -flto
LDFLAGS += -flto

ABCREV := default

[cliffordwolf]

LGTM besides the show-related nitpick

[whitequark]

@cliffordwolf There's another question, related to this PR. For nMigen I would really like to have a PyPI package with small (~low single MB at most) wasm code and equally small (~single seconds on midrange laptop at most) cold startup latency. To do this I pretty much have to remove any pass nMigen doesn't use. Currently that's not really doable in a nice way and I resort to overriding OBJS in the Makefile invocation, which is quite awful.

Do you think it would make sense to add a Makefile function for adding a pass and its dependencies so that it's possible to do something like make PASSES="read_ilang proc write_verilog" and have it work? And can you think of a way to untangle the circular dependencies between read_verilog/read_ilang and kernel/design?

[syrusakbary]

This is awesome! Congrats on the work 🎉

I'd love to try running it with Wasmer and the LLVM backend, I curious to know if the speeds will be closer to native. Could be possible to share the wasm somewhere?

Note: If you want, you can also try it with:

curl https://get.wasmer.io -sSfL | sh
# Note we use a single `:` as separator, instead of `::`
wasmer --backend=llvm --mapdir=/share:share --dir=. ./yosys.wasm -- -p synth_ice40 picorv32.v

[whitequark]

@syrusakbary yosys.zip

[syrusakbary]

Thanks!!

[syrusakbary]

I just tried it with wasmer (0.16.2) and comparing (just startup time) vs wasmtime (0.16):

Wasmtime: 0.387s

➜  time wasmtime /Users/syrusakbary/Downloads/yosys.wasm -- -V
Yosys 0.9+2406 (git sha1 bfbc120a, clang 10.0.0 -Os)
wasmtime /Users/syrusakbary/Downloads/yosys.wasm -- -V  0.31s user 0.08s system 98% cpu 0.387 total

Wasmer - LLVM: 0.072s

➜  time wasmer /Users/syrusakbary/Downloads/yosys.wasm --backend=llvm -- -V
Yosys 0.9+2406 (git sha1 bfbc120a, clang 10.0.0 -Os)
wasmer /Users/syrusakbary/Downloads/yosys.wasm --backend=llvm -- -V  0.05s user 0.02s system 97% cpu 0.072 total

Wasmer - Cranelift: 0.081s

➜  time wasmer /Users/syrusakbary/Downloads/yosys.wasm --backend=cranelift -- -V
Yosys 0.9+2406 (git sha1 bfbc120a, clang 10.0.0 -Os)
wasmer /Users/syrusakbary/Downloads/yosys.wasm --backend=cranelift -- -V  0.05s user 0.03s system 98% cpu 0.081 total

If you provide it me with some command that I can execute to measure runtime speed, that would be great... I expect wasmer speed with LLVM backend should be very close to native.

Extra! 🎉

I just tried yosys.wasm online... it works on the WebAssembly shell!
(you will need to drag and drop the wasm)

Note: if yosys is published to WAPM, the yosys command will be automatically available for anyone (without the drag & drop hassle 😝) , I can publish it there for you if it's more convinient!

[whitequark]

I can publish it there for you if it's more convinient!

The file I gave you is a highly limited and highly experimental development artifact. I really don't think it should be delivered to any end user without a significant amount of polishing going into it first.

In my case, Yosys (in the role of a Verilog backend) is an implementation detail of nMigen, so I can be sure it never has to deal with unexpected input or handle errors gracefully.

[syrusakbary]

The file I gave you is a highly limited and highly experimental development artifact. I really don't think it should be delivered to any end user without a significant amount of polishing going into it first.

Yeah, no worries! I will not publish it anywhere... excited for the polishing phase! :)

Is there any command that you recommend to run inside yosys to assess the runtime performance of Wasm runtimes?

[whitequark]

Is there any command that you recommend to run inside yosys to assess the runtime performance of Wasm runtimes?

Try synth_ice40 on some reference design, e.g. PicoRV32. But note that you'll need to rebuild with abc (or you could ask me to do that).

[whitequark]

@eddiehung Thanks for review! Yosys on WASI will still currently fail to build due to outdated abc revision checked out by the build system on master. What's the process for updating that?

[eddiehung]

@eddiehung Thanks for review! Yosys on WASI will still currently fail to build due to outdated abc revision checked out by the build system on master. What's the process for updating that?

Update this in your PR:

yosys/Makefile

Line 139 in bbde241

ABCREV = d14acd8

[whitequark]

Update this in your PR

Ah, so no process is necessary beyond the actual required techical step, gotcha.

[whitequark]

@syrusakbary I happened to rebuild Yosys with abc just now, so here you are:
yosys.zip