Open andreaskuster opened 2 years ago
Hi @andreaskuster Only to clarify, I am simply a recent user of cocotbext-axi.
I can't right now, but I will try to reproduce it and let you know. Let me say that I ran verilator --version
in my Ubuntu 20.04 and it reported Verilator 4.028 2020-02-06 rev v4.026-92-g890cecc1
(are you sure that you are trying 1.106? seems extremely old).
Thanks for your reply. And yes you were right, i meant version 4.106
(fixed it in the description), and the compatibility issue with newer versions i mentioned is according to the cocotb github issues and the comment here: https://docs.cocotb.org/en/stable/simulator_support.html
Furthermore, i tested different (older) versions of cocotbext-axi, with the same behaviour, so this problem seems to be present for a while.
Ok, I didn't know about the cocotb limitation using Verilator. I generally use cocotb with GHDL or iverilog.
Sure, ghdl and iverilog are fine, as long as you work with vhdl or verilog. However, I am currently extending a project written in SystemVerilog, which is why I would like to get verilator up to speed.
Well, it is not really a limitation by design, but rather the devil that comes with the fact that verilator is extending the VPI infrastructure. This should eventually become compatible again.
However, I am not sure if verilator is really to blame here, since the latest (v1.6.1) cocotb basic examples seem to work with verilator v4.106
. However, it is difficult for me to debug the issue, since this co-routine based code seems to be stuck in an infinity loop, but I do not understand the cause yet. @alexforencich Please let me know if you have any insights or clues that I can help with.
I'm not sure what the problem is here. But I'm also not going to do anything with verilator until https://github.com/verilator/verilator/issues/2778 is resolved so that cocotb will work correctly with current versions of verilator.
Yeah sure I can understand that. Thanks for your clarification. Let's keep this open and come back as soon as verilator has been fixed.
BTW: cocotbext-axi
+ questasim
works well for systemverilog.
I mean, it's also possible that I introduced some sort of bug recently that only affects verilator. So it's probably still worth getting to the bottom of what's going on here. Previously, I think I have tested this on verilator 4.106, and it worked fine. But there have been some changes since then, although I can't think of any change in particular that might have affected verilator specifically.
I think that the problem either exists for a longer time, or it is already broken in verilator 4.106, since I tried different, older version combinations of cocotbext-axi and cocotb, but with the very same result of getting stuck.
@andreaskuster I was also facing this issue, where after I upgraded several libraries the simulation for my previously working project got stuck. I'm using Verilator 4.106
, and was using a previous release of cocotb and cocotbext-axi. It turns out the issue was with cocotb-bus, where earlier I was using version 0.1.1
and after the upgrade, it was 0.2.1
.
Reverting cocotb-bus to version 0.1.1
worked for me. And this works with even the newest cocotb and cocotb-ext versions.
pip3 install cocotb-bus==0.1.1
When a bus version > 0.1.1
is used the reset never gets asserted. I don't know why reset is affected. But hopefully, this solution helps.
Thanks @SabraO, this indeed did the trick!
I opened a PR #37 to fix this.
Thanks a lot for this great project! @alexforencich @rodrigomelo9
I am trying to run the
axi-verilog
designs usingverilator
, however, this library does not seem to be compatible with verilator. I use version4.106
which should be compatible with cocotb (all their base examples work).However, it seems as if the simulation tests are stuck here: https://github.com/alexforencich/cocotbext-axi/blob/master/cocotbext/axi/axi_master.py#L413
Commands for reproduction:
running
make
withoutSIM=verilator
worksThe log for the axi test is: