SystemVerilog Improvements

[lorenzschmid]

Adds improvement for the SystemVerilog generation, namely:

• Puts module ports on a separate line (cosmetic only)
• Dedicated support for SystemVerilog via sv flag: Replaces generic always process statement with always_ff (sequential) and always_comb (combinatorial)
• Adds support for synchronous resets respecting global rst_sync and its corresponding flag, ff-reset (already supported by VHDL):
  • synchronous reset:

    always_ff @(posedge(aclk))
    begin
    if (!areset_n)
     ...
    else
     ...
    end

  • asynchronous reset:

    always_ff @(posedge(aclk) or negedge(areset_n))
    begin
    if (!areset_n)
     ...
    else
     ...
    end

• Adds support for active high resets (next to active low resets)

Introduces a new global variable, hdl_lang inside cheby.hdl.globals.gconfig to distinguish between Verilog and SystemVerilog generation.

[tgingold-cern]

Ok for me (once the failure is fixed: I don't think you can put an event control inside an always_comb).

[lorenzschmid]

So I fixed it by introducing two "dialects", one for Verilog (old behavior) and one for SystemVerilog (new behavior). This introduces a new global variable, hdl_lang inside cheby.hdl.globals.gconfig to distinguish between the two.

As far as I am aware, cheby does not put any events insides its combinatorial process, no? The error shown in the Github Action above, originates from the fact that always_comb does not support sensitivity lists.

Let me know if you agree on the new global variable or if you prefer choosing a different approach.

[tgingold-cern]

It's OK with me.

[lorenzschmid]

Sorry, forget to remove the draft status. Ready to be merged now.

[stefanlippuner]

I think it would make sense to also switch the SV generation & elaboration tests to SystemVerilog.

Overall, I'm not too sure how useful the 'verilog' dialect is. I saw quite a few files that were using 'interface' ports. As far as I know, this is not part of the Verilog spec. Maybe it would be easier and cleaner to only have the SystemVerilog version?

[tgingold-cern]

Unfortunately, we still need verilog. We have old Xilinx fpga in use, which require ISE. And SV support in ISE is not very good. We simply don't try to support everything with plain old verilog.