Bad assignment in CXXRTL under specific conditions

[flaviens]

Version

Yosys 0.37+21 (git sha1 3d9e44d18, clang 10.0.0-4ubuntu1 -fPIC -Os)

On which OS did this happen?

Linux

Reproduction Steps

Hi there!

I stumbled into an issue where CXXRTL makes bad assignments, apparently under very specific conditions. Here is a repository for you to reproduce the issue. The issue survives tracing, which is convenient.

Please let me know if you require any more information.

Thank you! Flavien

Expected Behavior

The left-hand side out_0 of the assignment gets the value of the right-hand side, eventually providing the value 0.

Actual Behavior

The left-hand side out_0 of the assignment gets a wrong value 1.

[whitequark]

I have run your testbench and there are several issues, as usual. First, it does not work in Icarus:

top.sv:10: error: Port in_data of module top is declared as input and as a reg type.
tb_icarus.sv:6: warning: input port in_data is coerced to inout.
tb_icarus.sv:13: error: in_data['sd31:'sd0]Part select is double-driving unresolved wire.
tb_icarus.sv:14: error: in_data['sd63:'sd32]Part select is double-driving unresolved wire.
tb_icarus.sv:15: error: in_data['sd95:'sd64]Part select is double-driving unresolved wire.

Second, the output with CXXRTL is:

CXXRTL
Output with CXXRTL 0

[whitequark]

This is at commit 3c3788ee287017802c1b77879b5f8e9ceb1be8ec.

[flaviens]

Hi @whitequark, thank you for your feedback!

1. Regarding Icarus, can you please tell me which version you are using? It is classical to get issues because of older versions.
2. Regarding CXXRTL, this is puzzling. I tried with the Yosys commit you said and still get the 1. I'll try inside a Docker container and get back to you.

[whitequark]

I'm using "Icarus Verilog version 11.0 (stable) ()"

[flaviens]

Hi Whitequark, thank you for your patience!

1. I think the Icarus version that you are using is a bit too old unfortunately.
2. The issue seems dependent on the GCC version installed.

I created a Docker image in the repository to make it most convenient for you.

[whitequark]

Please minimize the testcase further than this. In particular the two-level "wrapper_cxxrtl.sv" / "top.v" structure is making triage of your issues more difficult. In this particular case, I think you should also be able to remove some of the redundant arithmetics.

[flaviens]

Thank you Whitequark for your update! In this commit, I:

• Flattened the hierarchy as per your request.
• Adopted a naming scheme that tells the expected value of each signal to further assist the debug process.

Substituting any further arithmetics line would make the bug disappear, hence it is hard to simplify further on this specific aspect.

Thank you! Flavien