The 'flatten' command adds always/if statements that weren't in the original code

[yurivict]

Version

Yosys 0.30+1 (git sha1 5813809ad, gcc 12.2.0 -fPIC -Os)

On which OS did this happen?

Linux

Reproduction Steps

        read_verilog x.v"
        flatten top"
        select -module top"
        write_verilog -selected x.flattened.v"

Expected Behavior

Produce an equivalent flattened verilog code.

Actual Behavior

The 'flatten' command adds the lines like these:

 always @* begin
    if (\$auto$verilog_backend.cc:2097:dump_module$16 ) begin end
    _00_ = _44_[7:0];
  end

  always @* begin
    if (\$auto$verilog_backend.cc:2097:dump_module$16 ) begin end
    _01_ = _02_;
  end

[whitequark]

The if (\$auto$verilog_backend.cc:2097:dump_module$16 ) begin end statements are necessary for that always @* block to be executed at time zero in Verilog simulators. (I was the one who added it, IIRC.)

The write_verilog command does produce a Verilog file that behaves equivalently to the netlist you gave it--in fact it would not be equivalent otherwise. But it does differ structurally.

[yurivict]

The if (\$auto$verilog_backend.cc:2097:dump_module$16 ) begin end looks like a hack.

Can't Verilog simulators read the always @* statement and just execute it at time zero without these lines?

[whitequark]

The if (\$auto$verilog_backend.cc:2097:dump_module$16 ) begin end looks like a hack.

I agree. The same is true of Verilog in general. It is a poorly designed language that should not be used.

Can't Verilog simulators read the always @* statement and just execute it at time zero without these lines?

Then they would not be compliant with the Verilog specification that is quite explicit about what does and does not happen at which time.

[yurivict]

Then they would not be compliant with the Verilog specification that is quite explicit about what does and does not happen at which time.

But if these lines were not in the original Verilog and they somehow alter the behavior of Verilog simulators this means that the flattened Verilog would have different behavior in simulators.

---

In any case, I think that yosys should have a way to disable these. Maybe there should be an option that would disable it.

[whitequark]

But if these lines were not in the original Verilog and they somehow alter the behavior of Verilog simulators this means that the flattened Verilog would have different behavior in simulators.

Yosys is not a general purpose Verilog manipulation tool but a tool for synthesis (and verification as a part of synthesis-like flow). I said that the behavior of the output Verilog is equivalent to the netlist you gave it, not to the input Verilog (which it is not).

The behavior of the input Verilog you read with read_verilog and the netlist that is used for synthesis differ because Verilog synthesizers are not fully compliant with the Verilog standard; they instead interpret a subset of the Verilog language using their own rules, and a designer may, with great care, use Verilog simulators to approximate the behavior of the post-synthesis netlist.

In any case, I think that yosys should have a way to disable these. Maybe there should be an option that would disable it.

Perhaps; the write_verilog command has a lot of options that tweak compatibility already. However, you should not expect Yosys to roundtrip arbitrary Verilog (even arbitrary synthesizable Verilog) in a way that leaves semantics completely intact for event-driven simulation. This is not something Yosys is suitable for: "sys" in "Yosys" stands for "synthesis suite".

[jix]

Note that you can already use write_verilog -sv to use SystemVerilog's always_comb instead of always @* in which case the manual execute-at-zero trigger hack is not emitted (because always_comb does execute at time zero automatically).

[nakengelhardt]

@yurivict What exactly are you trying to do that these lines are preventing you from doing?

[yurivict]

I just need to flatten the design and get a flattened equivalent. My system does Verilog structure analysis and computes something based on structure. It doesn't need to have any added elements.

[nakengelhardt]

If you need to preserve the original verilog structure, Yosys is not the right tool for that use case. Some people have had good success with using slang for verilog-to-verilog transformations, maybe you can try that: https://github.com/MikePopoloski/slang