Cosimulation with verilator?

Hi all,

I would like to perform cosimulation with verilator, due to its systemverilog language support.
Some 10 years ago, mentioned in the sourceforge myhdl-list, an experiment was done by Terry Chen. Not sure if anyone has been using his method, or maybe another alternative?


Not direct experience of verilator, but we have extensively used an external simulator (Vivado) through a different approach to true cosimulation which might be relevant here.

This work is encapsulated with Veriutils and Ovenbird. The former is the entry point, and the latter extends Veriutils to target Vivado. The model is that you build python test bench with a bit of (generally helpful) syntactic constraints, and then the tool will automatically wrap the DUT in an equivalent test bench, capturing all the signals and reporting back. It is this wrapped test object which is pure Verilog/VHDL which you can then run in a simulator.

It handles normal signals which have precise timing as well as AXI stream signals in which a convertible BFM is used (for e.g. the case where the DUT uses closed IP which we just model in the python world).

We’ve used this model extensively and with good effect on a large project. The tools are well tested and trusted.

I’m happy to give more assistance if this seems interesting to you…

(I’ve just realised, I haven’t pushed some significant changes to the above repos which don’t change much feature-wise - just filling in a couple of gaps - but were a significant refactoring to make extending easier, so probably relevant to you. I’m just on this now)

With the help of Wilson Snyder we have created a cosimulation interface with Verilator. We have been running it extensively for some years. We were planning to provide this to the community but got stuck since our flow, far various reasons, is stuck at MyHDL 0.8.


Henry, thanks. I’ll have a look at it. Did not realize vivado sim is an option as well (for working at home). I realized that Verilator, since it is in fact also pure RTL, is a natural match with MyHDL so it still might be interesting.


Kenny, I’m looking at Is that what you are referring to? I will give it a try. Maybe a pull request for which also is valid fo rthe current myhdl versions.
Thanks for sharing, I will give it a try.


Yes, that is the one. But unfortunately that pull request has a number of bugs. We have done a lot of work to get it working but that is not pushed anywhere. I’ll take a look if there is an easy way to share it with you.

Yeah, we use Vivado extensively with MyHDL, and pretty much exclusively with the free version. Ovenbird is the tool we’ve created for verification. Also relevant might be Kea which is useful tools that fit nicely into the Xilinx ecosystem, including a nice register subsystem.

Hi Kenny,

Did you have a look whether you can share? I guess myhdl/ and the cosimulation/verilator/ directory should get me going. Then I’ll prepare a pull request.


I’ve created a pull request to add verilator as a means for cosimulation.
See, branch verilator.
I used ‘pyverilator’ to ease integration. It is a specific version which allows easy dictionary access to io-ports.
No interprocess communication is used since the verilated design is imported as a ctypes module.

Not much testing has been done, but few tests have been added.

What I noticed is that both this verilator cosim, but also other cosims like icarus, have some initialization/reset issues which deserve some attention. They behave slightly different than pure myhdl.

Also, I considered to not use pyverilator and rewrite directly for verilator directly, but with this pyverilator version it was more convenient. but anyway, something to reconsider.

I have no performance numbers yet so I’m interested in your experience. Of course there is always room improvement. Also bug reports are welcome, if any.


@jos.huisken Is this suitable for merging into master? It seems like a good addition. Aren’t the tests provided through the MyHDL tests?

@hgomersall I think so. Added indeed few tests which should also pass when there is no pyverilator+verilator available. So it should not break anything.

In that case I encourage you to raise a pull request when you’re happy with it.

@hgomersall Created pull request #338.
@kranerup I saw that Wilson Snyder created a pull request some time ago which somehow failed.
Lets hope this one makes it, despite the dependence on the non-standard pyverilator.

How do you mean non-standard? It’s just a python package isn’t it?