ProbeSpec and HarnessSpec tests fail

[rameloni]

Type of issue: Bug Report

Please provide the steps to reproduce the problem: I have updated my fork to the latest commit and now it fails the following tests when I run sbt test locally. They also fail if I clone the main branch (not my fork):

• chiselTests.ProbeSpec: "Probe force/release reg example" should "work in simulator" at lines: https://github.com/chipsalliance/chisel/blob/3c55851443f0cb5a791088b64cf9d2db6cf0d5bf/src/test/scala/chiselTests/ProbeSpec.scala#L649-L653
• chiselTests.HarnessSpec fails after I updated to latest verilator version due to #error "Verilator requires a C++14 or newer compiler"

What is the current and expected behavior?

• ProbeSpec: reg is 123 instead of being cycle. These lines https://github.com/chipsalliance/chisel/blob/3c55851443f0cb5a791088b64cf9d2db6cf0d5bf/src/test/scala/chiselTests/ProbeSpec.scala#L645-L648 expect that dut.b.refs.reg is forced to cycle and dut.b.refs.out to 123.U.
• HarnessSpec: I have seen that the error is due to this line https://github.com/chipsalliance/chisel/blob/3c55851443f0cb5a791088b64cf9d2db6cf0d5bf/firrtl/src/main/scala/firrtl/util/BackendCompilationUtilities.scala#L153

Please tell us about your environment:

• version: main dev branch
• OS: Ubuntu 20.04.6 LTS
• verilator: 5.024 2024-04-05 rev v5.024

Other Information

What is the use case for changing the behavior?

[jackkoenig]

I have been debugging this a bit, so far I have gathered that ProbeSpec - Probe force/release reg example works in Verilator v5.022 and earlier, but fails in v5.024 (the latest version of Verilator). I'm working on turning it into something we can report to Verilator.

[rameloni]

Thanks, I downgraded to v5.022 and it works. For the HarnessSpec instead, it simply needs to update the BackendCompilationUtilities from c++11 to c++14.

[dtzSiFive]

In that test, ProbeSpec looks to be forcing the same net twice (output port which is just assign out = r;).

Not sure that's something to rely on the behavior of. When have cycles hope to circle back and suggest how to change the test and/or diagnose this further, but thoughts welcome until then.

[jackkoenig]

@dtzSiFive you understand Verilog force semantics better than I do, so please check my work but I think this is a bug in Verilator, I filled a minimized test case: https://github.com/verilator/verilator/issues/5062

[jackkoenig]

This has been fixed in Verilator, see https://github.com/verilator/verilator/pull/5105, until the next version including the fix is released (presumably v5.026), folks should continue to use Verilator v5.022.