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)
committerwhitequark <whitequark@whitequark.org>
Wed, 26 Aug 2020 16:51:12 +0000 (16:51 +0000)
commit12beda6e5b1de4a3801098f14b819e91eb63e0f3
treecca83361e94d775719312462ff0ed50bab2abfbd
parent6d9852506fb2880d1cca2bc2fec44c408eebb99f
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