Open wzab opened 1 year ago
It seems that this is related to using undocumented features of Verilator. In https://github.com/verilator/verilator/issues/2152 it is clearly stated in https://github.com/verilator/verilator/issues/2152#issuecomment-581882530 :
Avoid peeking into the model internals (anything with DOT). Just use $readmemh in your verilog. If this operation needs to be triggered from C++, then use a DPI export call.
So probably, the memory should be initialized with $readmemh
.
I have prepared a work around, allowing me to generate the J1B firmware with Verilator on current Debian/testing. Please see https://github.com/jamesbowman/swapforth/compare/master...wzab:swapforth:new_verilator_and_python (or https://github.com/wzab/swapforth/commit/b8c747e05c7e3c59216bd1c39db2eb7f50b55fd3 )
FWIW, the reason you're seeing this issue is because starting from Verilator version 4.210, the model class is an interface object. I created a pull request a while back that points to the correct internal object locations (well for the newer 4.x versions at least): https://github.com/jamesbowman/swapforth/pull/76
I do agree it's better to not use internals.
I'm using a Debian/testing system with
Verilator 5.006 2023-01-22 rev (Debian 5.006-3)
When I try to runlocaltest
inswapforth/j1b/verilator
directory, I get the following error: