VTR standard benchmarks behave abnormally with '-parser system-verilog'

[Junius00]

Expected Behaviour

There was no mention of a specific parser to use in the documentation of these benchmarks.

Current Behaviour

Some of the VTR benchmarks will fail when the parser is set to system-verilog.

• With the VPR error message 'only rising-edge latches are supported': 'bgm', 'boundtop', 'ch_intrinsics', 'or1200', 'raygentop', 'stereovision3'
• With a majority of the circuit swept away: 'mkDelayWorker32B', 'mkPktMerge', 'mkSMAdapter4B'
  • The resultant circuit works, but is very small compared to the intended circuit.

Possible Solution

Leaving the parser argument unset leaves no issue. Perhaps this ought to be documented in the documentation of these benchmarks, that these benchmarks have to be used with a specific parser.

Steps to Reproduce

1. Use one of the problematic VTR standard benchmarks, under vtr_flow/benchmarks/verilog.
2. Use any architecture file. (I replicated this issue with vtr_flow/arch/COFFE_22nm/stratix10_arch.xml)
3. python vtr_flow/scripts/run_vtr_flow.py <design> <arch> -parser system-verilog.

Context

We left the parser at system-verilog since some benchmarks we were using were written in SV. We didn't expect the parser to affect these benchmarks.

Your Environment

• VTR revision used: commit ce706d5
• Yosys manually downgraded to v0.32
• Operating System and version: Ubuntu 22.04 LTS

[vaughnbetz]

Thanks @Junius00.
@amirarjmand93 : any idea what is going on here? I'm not sure what the current status of SV support is in recent VTR ... do we need to set a cmake flag to enable systemVerilog? Does that work now?

In any case we should either fix or document this.
Adding @AlexandreSinger since he has also been involved in testing SystemVerilog support.