The localtest doesn't work with Verilator 5.xxx

[wzab]

I'm using a Debian/testing system with Verilator 5.006 2023-01-22 rev (Debian 5.006-3)
When I try to run localtest in swapforth/j1b/verilator directory, I get the following error:

$ ./localtest
verilator --l2-name v -Wall -I../verilog/ --cc j1b.v ../verilog/j1.v ../verilog/stack.v --top-module j1b --exe sim_main.cpp
make -C obj_dir CXXFLAGS="-fPIC" OPT_FAST="-O2" -f Vj1b.mk Vj1b
make[1]: Entering directory '/tmp/rr/swapforth/j1b/verilator/obj_dir'
g++ -fPIC -I.  -MMD -I/usr/share/verilator/include -I/usr/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-sign-compare -Wno-uninitialized -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -Wno-shadow       -O2 -c -o sim_main.o ../sim_main.cpp
../sim_main.cpp: In function 'int main(int, char**)':
../sim_main.cpp:23:12: error: 'class Vj1b' has no member named 'v__DOT__ram'
   23 |       top->v__DOT__ram[i] = v;
      |            ^~~~~~~~~~~
make[1]: *** [Vj1b.mk:61: sim_main.o] Error 1
make[1]: Leaving directory '/tmp/rr/swapforth/j1b/verilator/obj_dir'
make: *** [Makefile:9: obj_dir/Vj1b] Error 2

[wzab]

It seems that this is related to using undocumented features of Verilator.
In verilator/verilator#2152 it is clearly stated in verilator/verilator#2152 (comment) :

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.

[wzab]

I have prepared a work around, allowing me to generate the J1B firmware with Verilator on current Debian/testing.
Please see master...wzab:swapforth:new_verilator_and_python
(or wzab@b8c747e )

[stuij]

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): #76

I do agree it's better to not use internals.