back.verilog: omit Verilog initial trigger only if Yosys adds it.
authorwhitequark <whitequark@whitequark.org>
Wed, 26 Aug 2020 09:01:57 +0000 (09:01 +0000)
committerLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Fri, 31 Dec 2021 15:06:43 +0000 (15:06 +0000)
commitd2eb7031fe2ec5f1614a91746ff5c6c96c88dd93
treed0e2b74b2ae66875d8825b740a6935abbcd9442c
parent3a175a829ce3056e70f0177a25aaf6fd59c1816d
back.verilog: omit Verilog initial trigger only if Yosys adds it.

Verilog has an edge case where an `always @*` process, which is used
to describe a combinatorial function procedurally, may not execute
at time zero because none of the signals in its implicit sensitivity
list change, i.e. when the process doesn't read any signals. This
causes the wires driven by the process to stay undefined.

The workaround to this problem (assuming SystemVerilog `always_comb`
is not available) is to introduce a dummy signal that changes only
at time zero and is optimized out during synthesis. nMigen has had
its own workaround, `$verilog_initial_trigger`, for a while. However,
`proc_prune`, while increasing readability, pulls references to this
signal out of the process. Because of this, a similar workaround was
implemented in Yosys' `write_verilog` itself.

This commit ensures we use our workaround on versions of Yosys
without the updated `write_verilog`, and Yosys' workaround on later
versions.

Fixes #418.
nmigen/back/verilog.py