Dolu1990

Currently cocotb with nvc => *\* Fatal: VHPI function vhpi_get_phys not implemented

If i fake the vhpi_get_phys it to further : ``` 0.00ns INFO cocotb.gpi gpi_embed.c:248 in embed_sim_init Running on nvc version 1.1-devel 0.00ns INFO cocotb.gpi gpi_embed.c:249 in embed_sim_init Python interpreter initialised...

Greate : D No i get : ``` 0.00ns INFO cocotb.gpi gpi_embed.c:248 in embed_sim_init Running on nvc version 1.1-devel 0.00ns INFO cocotb.gpi gpi_embed.c:249 in embed_sim_init Python interpreter initialised and cocotb...

If i remember well, the lock was reducing the bandwidth by 75%. In practice when 4 CPU were doing busy work, it realy hit the performances.

You can go to the tutorial map, Near the end, there is a testbench with this function used.

i thing @lambdaShade did it. personnaly i dont't care ^^

My only sadness is that both minecraft and github are owned by M$

Hooo right, nice catch ^^ I would say, changing : https://github.com/SpinalHDL/VexRiscv/blob/4fff62d3feeb05edcea46e66b25de0ecf3f274fa/src/main/scala/vexriscv/plugin/CfuPlugin.scala#L196 into val fired = RegInit(False) setWhen(bus.cmd.fire) clearWhen(!arbitration.isStuck) would fix it. @davidlattimore Do you have the flow in place to...

ahhh got amaranth up, but got some issue with meson package, my python setup is completly broken ^^

I pushed the VexRiscv fix in both dev and master branches. and also in the litex python data repo. So, if you update litex, all should be good. let's me...