Typedef interface class in pyhdl_if.sv

[PrashanthPoobalan]

Hi all,
first off I must say how excited I am for this pyhdl-if project, to allow easier HW/SW codesign & integration for a more complete python verification platform. I am going through the cocotb call_sv_bfm example to build an intuition of the underlying mechanisms.

Initially I had to modify the Dockerfile as I got an error complaining that cocotb only supports Verilator >= v5.036 like this :

RUN git clone https://github.com/verilator/verilator.git && \
    cd verilator && \
    git checkout v5.038 && \
    autoconf && \
    ./configure && \
    make -j"$(nproc)" && \
    make install

then executing make I ran into this error :

%Error: /work/pyhdl-if/src/hdl_if/share/dpi/pyhdl_if_icall_api.svh:21:11: Interface class shall not be nested within another interface class. (IEEE 1800-2023 8.26)
   21 | interface class ICallApi;
      |           ^~~~~
        /work/pyhdl-if/src/hdl_if/share/dpi/pyhdl_if.sv:201:1: ... note: In file included from 'pyhdl_if.sv'
        ... See the manual at https://verilator.org/verilator_doc.html?v=5.038 for more assistance.
%Error: Exiting due to 1 error(s)
make[1]: *** [/work/pyhdl-if/examples/call/cocotb/call_sv_bfm/example_venv/lib/python3.12/site-packages/cocotb_tools/makefiles/simulators/Makefile.verilator:61: sim_build/Vtop.mk] Error 1
make[1]: Leaving directory '/work/pyhdl-if/examples/call/cocotb/call_sv_bfm'
make: *** [/work/pyhdl-if/examples/call/cocotb/call_sv_bfm/example_venv/lib/python3.12/site-packages/cocotb_tools/makefiles/Makefile.inc:17: sim] Error 2

Which seem to suggest that the typedef interface class in the pyhdl_if.sv is tripping the verilator syntax check when the compiler encounters the include expansion later in the pyhdl_if.sv here :

    `include "pyhdl_if_taskcall_closure.svh"
    `include "pyhdl_if_icall_api.svh"                          #  <----- Here
    `include "pyhdl_if_call_init.svh"
    `include "pyhdl_if_call_api.svh"
    `include "pyhdl_if_call_dpi.svh"

    `include "pyhdl_if_tlm_init.svh"

    `include "pyhdl_if_init.svh"

Has anyone else encountered this issue before?
Is the typedef interface class ICallApi in pyhdl_if.sv causing this problem?
And could anyone help advise this ?

Cheers

[mballance]

Hi @PrashanthPoobalan, thank you for this issue report. I see a similar report in #34 as well.
This code worked as of Verilator 5.029 (and likely later), but I confirm that I see the same thing with Verilator 5.040. Because this code works with commerical SystemVerilog simulators, I'm inclined to view this as a bug in Verilator. If you're able to move back to an earlier version of Verilator, this may be a good workaround.

[mballance]

Just a heads-up that I've identified a presumed Verilator issue/regression and a workaround that can be applied in the pyhdl-if library. Try v0.0.5 of pyhdl-if and let us know if you face further issues.

[PrashanthPoobalan]

H @mballance

Thanks for the quick followup an the v0.0.5 update to address the verilator issue.

Just tried again with the pyhl-if v0.0.5 fix and the verilator 5.040 tag, however I am still seeing the same error

Does this mean that the best verilator version to stick to is the older verilator 5.029?
but when I tried to run make in verilator 5.028 tag

RUN git clone https://github.com/verilator/verilator.git && \
    cd verilator && \
#    git checkout v5.040 && \
    git checkout v5.028 && \

I'm getting the error stating cocotb requires Verilator 5.036 or later, but using 5.028

(example_venv) root@8e5070c6edc9:/work/pyhdl-if/examples/call/cocotb/call_sv_bfm# make
/work/pyhdl-if/examples/call/cocotb/call_sv_bfm/example_venv/lib/python3.12/site-packages/cocotb_tools/makefiles/simulators/Makefile.verilator:29: *** cocotb requires Verilator 5.036 or later, but using 5.028.  Stop.

Indicating that I can't make this example with any verilator tag less than 5.036.
Hence I am forced to use the either 5.036, 5,038 or 5.040 tags as seen in the options shown here :

all of which ( 5.036, 5,038 or 5.040 ) giving me the same Interface class shall not be nested within another interface class. (IEEE 1800-2023 8.26) error signature.
Is there a specific combination of Verilator and phydl-if versions you'd recommend, or perhaps any edits to the System Verilog/ Python source code to bypass this potential bug in Verilator?

I'd be happy to test any patch or workaround since you're trying this on verilator 5.040 on your end as well.

Thanks again for your guidance !

Best
Prashanth

[mballance]

Hi Prashanth,
I had overlooked that you were using the cocotb version of the example, and did my testing with the pure-DPI version.
The key workarounds are to the code generator. This means that you'll need to manually remove hdl_call_if_api.svh before running to ensure that the Makefile re-generates this file. You'll also need to explicitly import pyhdl_if in call_sv_bfm.sv.

module WishboneInitiatorBFM(
    input           clock,
    input           reset,
    output reg[31:0]        adr,
    output reg[31:0]        dat_w,
    input[31:0]             dat_r,
    output                  cyc,
    input                   err,
    output reg[3:0]         sel,
    output                  stb,
    input                   ack,
    output reg              we
);      
    import pyhdl_if::*;
    `include "hdl_call_if_api.svh"

I just pushed an updated version of this file with the fix applied. So:

• Update your source to get the fix to call_sv_bfm.sv
• Manually remove hdl_call_if_api.sv
• Re-run

Hope this helps!

Best Regards,
Matthew

[PrashanthPoobalan]

Hi @mballance
Thanks for the support I really appreciate it !

I followed the recomended steps and also cloned your recently edited commit(both seem to result in the same error):

1. I Updated the call_sv_bfm.sv

2. Deleted the hdl_call_if_api.svh, so the Makefile would regenerate this hdl_call_if_api.svh

3. re-run the make

Good news, there seems to be some progress, I am no longer seeing the previous error signature Interface class shall not be nested within another interface class. (IEEE 1800-2023 8.26)

but now I am getting a new error that appears to be from the Verilator internal C++ compiler :

In file included from Vtop__Syms.h:26,
                 from Vtop__pch.h:24,
                 from Vtop.cpp:4,
                 from Vtop__ALL.cpp:3:
Vtop_std__03a__03aprocess__Vclpkg.h: In member function ‘bool VlClassRef<T_Class>::operator==(const VlClassRef<T_OtherClass>&) const [with T_OtherClass = Vtop_std__03a__03aprocess; T_Class = Vtop_std__03a__03aprocess]’:
Vtop_std__03a__03aprocess__Vclpkg.h:68:20: error: ‘class Vtop_std__03a__03aprocess’ has no member named ‘__PVT__m_process’
   68 |     return m_objp->__PVT__m_process == rhs.m_objp->__PVT__m_process;
      |                    ^~~~~~~~~~~~~~~~
Vtop_std__03a__03aprocess__Vclpkg.h:68:52: error: ‘class Vtop_std__03a__03aprocess’ has no member named ‘__PVT__m_process’
   68 |     return m_objp->__PVT__m_process == rhs.m_objp->__PVT__m_process;
      |                                                    ^~~~~~~~~~~~~~~~
Vtop_std__03a__03aprocess__Vclpkg.h: In member function ‘bool VlClassRef<T_Class>::operator!=(const VlClassRef<T_OtherClass>&) const [with T_OtherClass = Vtop_std__03a__03aprocess; T_Class = Vtop_std__03a__03aprocess]’:
Vtop_std__03a__03aprocess__Vclpkg.h:74:20: error: ‘class Vtop_std__03a__03aprocess’ has no member named ‘__PVT__m_process’
   74 |     return m_objp->__PVT__m_process != rhs.m_objp->__PVT__m_process;
      |                    ^~~~~~~~~~~~~~~~
Vtop_std__03a__03aprocess__Vclpkg.h:74:52: error: ‘class Vtop_std__03a__03aprocess’ has no member named ‘__PVT__m_process’
   74 |     return m_objp->__PVT__m_process != rhs.m_objp->__PVT__m_process;
      |                                                    ^~~~~~~~~~~~~~~~
Vtop_std__03a__03aprocess__Vclpkg.h: In member function ‘bool VlClassRef<T_Class>::operator<(const VlClassRef<T_OtherClass>&) const [with T_OtherClass = Vtop_std__03a__03aprocess; T_Class = Vtop_std__03a__03aprocess]’:
Vtop_std__03a__03aprocess__Vclpkg.h:80:20: error: ‘class Vtop_std__03a__03aprocess’ has no member named ‘__PVT__m_process’
   80 |     return m_objp->__PVT__m_process < rhs.m_objp->__PVT__m_process;
      |                    ^~~~~~~~~~~~~~~~
Vtop_std__03a__03aprocess__Vclpkg.h:80:51: error: ‘class Vtop_std__03a__03aprocess’ has no member named ‘__PVT__m_process’
   80 |     return m_objp->__PVT__m_process < rhs.m_objp->__PVT__m_process;
      |                                                   ^~~~~~~~~~~~~~~~
make[2]: *** [/usr/local/share/verilator/include/verilated.mk:272: Vtop__ALL.o] Error 1
make[2]: Leaving directory '/work/pyhdl-if/examples/call/cocotb/call_sv_bfm/sim_build'
make[1]: *** [/work/pyhdl-if/examples/call/cocotb/call_sv_bfm/example_venv/lib/python3.12/site-packages/cocotb_tools/makefiles/simulators/Makefile.verilator:65: sim_build/Vtop] Error 2
make[1]: Leaving directory '/work/pyhdl-if/examples/call/cocotb/call_sv_bfm'
make: *** [/work/pyhdl-if/examples/call/cocotb/call_sv_bfm/example_venv/lib/python3.12/site-packages/cocotb_tools/makefiles/Makefile.inc:17: sim] Error 2

Build recepe :
pyhdl-if: v0.0.5
Verilator: 5.040

I am wondering if you are hitting on this C++ compiler error yourself too, or it could be a toolchain dep issue on my end.
Happy to test any patch/branch !

thanks again @mballance

Cheers,
Prashanth