Verilator support

[Risto97]

I done a series of pull requests in Verilator in order to support the code regblock is generating. In the next release 5.12 I believe most of the things will be supported. There are still some false linting errors that I still need to fix, but that's not too important.

In order to properly test if everything is supported I need to add a verilator support in your regression tests.

At the moment, I can see that some constructs are falling, like the double hash (##) you use in your testbenches. I am willing to take a look into issues that can be solved and supported easily.

First to ask you, would you be interested in merging verilator support as a part of your regression tests? And in case that some construct is not easily fixed in verilator, would you be willing to use an equivalent alternative in order to have verilator support?

[amykyta3]

That is great to hear!! I have been closely watching the progress of Verilator and have always wanted to enable it in the PeakRDL-regblock unit tests. I also ran into the ##0 delay limitation and ended up sticking with the free version of Questa. The ##0 synchronization mechanism is essential when using clocking blocks since it enables a reliable way to issue back-to-back transactions reliably, so I was not willing to compromise on that feature of SV.

I definitely would love to see a future where I can run Verilator as the primary simulator for regression tests. The current requirement to use Questa is a little cumbersome to new users that want to contribute.

[Risto97]

Well the first step is to file an issue at the verilator github. I will be filing issues when I have time for the things I find missing. Usually at least they provide a good pointers on how to resolve it, if someone doesn't resolve it. Recently there is a big effort to support verification features of SV, so I would say that there is a good chance that most of the work to support features you use is probably already done.

So far the things left to do are:

Regblock-generated code

• [ ] False multidriven warning on unpacked structures https://github.com/verilator/verilator/issues/4226

Regression testbenches

• [ ] ##0 feature https://github.com/verilator/verilator/issues/4263
• [x] disable fork https://github.com/verilator/verilator/issues/4125
• [ ] Quirks with variable lifetimes https://github.com/verilator/verilator/issues/4607
• [ ] Quirks with repeat statements https://github.com/verilator/verilator/issues/4451

[amykyta3]

Found an existing ticket for disable fork, and issued a new one for ##0 delays. Edited your comment to include links to them.

[drewranck]

Would it be possible to add Verilator lint waivers in the generated SV module?

I'd rather not turn off %Warning-MULTIDRIVEN for my entire project. In the meantime, I can make some automated edits to the generated SV module to work-around this. Verilator doesn't like multiple bits in structs to be set by separate processes (even though each field itself is not multi-driven), so I was going to guard the entire file with: // verilator lint_off MULTIDRIVEN (entire file) // verilator lint_on MULTIDRIVEN

[Risto97]

@drewranck

Did you think of using verilator configuration files, This is my approach to waive the particular linting message, until I get around to work on fixing it in verilator:

Create a file waivers.vlt

// DESCRIPTION: Verilator output: Waivers generated with --waiver-output

`verilator_config

lint_off -rule MULTIDRIVEN -file "*/apb_lfsr_regblock.sv" -match "*"

During verilation, just pass it along with other verilog files.

[drewranck]

@drewranck

Did you think of using verilator configuration files, This is my approach to waive the particular linting message, until I get around to work on fixing it in verilator:

Create a file waivers.vlt

That's a good suggestion, thanks! I'd have to fold that into my verilator build flow though, but easy enough.