[svsim] Initialize ports to zero (#4651)

Avoid problems with VCS xprop (either xmerge or tmerge) when using svsim
due to these features (seemingly) introducing spurious clock transitions
when enabled.

The change introduced in ab7c417 changes the behavior of svsim such that
the simulation body would run after all initial blocks.  Before this, the
simulation body ran during the testbench's initial block which would race
with other initial blocks.  However, after this change, VCS xprop
simulations started failing.  As far as I can tell, this is due to xprop
introducing a clock transition for the clock variable in the testbench
after initial blocks, but before the simulation body.  This would then
cause a number of assertions to evaluate and fail the simulation.

Fix this by initializing the variables used to drive inputs to the DUT to
zero instead of leaving them uninitialized.  An alternative approach would
be to use 2-state variables.

This may create problems with active-low asynchronous resets and trivial
reset schemes that do not show a reset edge.  With this commit, when an
asynchronous reset is applied, it will have to go through a `1 -> 0 -> 1`
transition so that flops that need to be reset see an edge (due to the
longstanding annoyance of Verilog where an active low asynchronous reset
flop is coded as if it was sensitive to a negative reset edge when it is
actually level sensitive).

Signed-off-by: Schuyler Eldridge <[email protected]>

Author: seldridge

svsim/src/main/scala/Workspace.scala

@@ -97,7 +97,7 @@ final class Workspace(
       l("module ", Workspace.testbenchModuleName, ";")
       for ((port, index) <- ports) {
         if (port.isSettable) {
-      l("  reg  [$bits(", dut.instanceName, ".",  port.name, ")-1:0] ", port.name, ";")
+      l("  reg  [$bits(", dut.instanceName, ".",  port.name, ")-1:0] ", port.name, " = '0;")
         } else {
       l("  wire [$bits(", dut.instanceName, ".",  port.name, ")-1:0] ", port.name, ";")
         }