Major Tools
Other Tools
General Info

Verilator signal reflection?

Added by Todd Strader over 4 years ago

I'd like to be able to access a /* verilator public */ given that signal's canonical name (e.g. "top.v.glbl.GSR"). I've been messing around with the VerilatedScope objects in the *__Syms class seem to give me part of what I want. I modified the t_trace_public_sig regression test to play around with this:

$ git diff
diff --git a/test_regress/t/t_trace_public_sig.cpp b/test_regress/t/t_trace_public_sig.cpp
index 4ad487d..d8e352a 100644
--- a/test_regress/t/t_trace_public_sig.cpp
+++ b/test_regress/t/t_trace_public_sig.cpp
@@ -11,6 +11,7 @@
 #include "Vt_trace_public_sig.h" 
 #include "Vt_trace_public_sig_t.h" 
 #include "Vt_trace_public_sig_glbl.h" 
+#include "Vt_trace_public_sig__Syms.h" 

 unsigned long long main_time = 0;
 double sc_time_stamp() {
@@ -22,6 +23,9 @@ const unsigned long long dt_2 = 3;
 int main(int argc, char **argv, char **env) {
     Vt_trace_public_sig *top = new Vt_trace_public_sig("top");

+    printf ("Symbol table name = %s\n", top->__VlSymsp->name());
+    top->__VlSymsp->__Vscope_v__glbl.scopeDump();

scopeDump() shows me the public signal in the GSR module:

vlt/t_trace_public_sig: Run
        obj_dir/t_trace_public_sig/Vt_trace_public_sig    > obj_dir/t_trace_public_sig/vlt_sim.log
Symbol table name = top
    SCOPE 0x1d1c540: top.v.glbl
       VAR 0x1d1c6f8: GSR
*-* All Finished *-*

And even better yet, I can discover GSR's type and access its data. However, I can't find a way to link scopes together. I'd like to be able to start with top or top's symbol table and get a VerilatedVar* for an arbitrary (public) signal in the design. Is this possible?

Replies (4)

RE: Verilator signal reflection? - Added by Todd Strader over 4 years ago

Alternatively (or even preferably) I'd like to be able read / write arbitrarily sized signals with DPI. But I cannot find a way to do this with Verilator since it does not support svOpenArrayHandle. I also tried assigning wires to strings (since Verilator does support strings via DPI), but this causes a Verilator abort.

RE: Verilator signal reflection? - Added by Jie Xu over 4 years ago

We have a patch to Verilator which exports basically all the signal in the design for C++ manipulation. In the end we can do interactive debugging of the design. For example, at a particular point of simulation, we can do "read" or "write 0x2".

To achieve this, we put all the signals into a "debug_var" scope. In order to access the signals, we extended the VerilatedVar to have info about the C++ object of the signal.

If you are interested, I can try to post the patch here.

RE: Verilator signal reflection? - Added by Todd Strader over 4 years ago

Thanks for the response. Couple questions:
  • How is this different than the --public flag?
  • Are you saying that you collect all signals in one VerilatedScope object?
  • Have you benchmarked the difference between running in this debug mode and not? How much does the debug mode slow things down?

I'm not entirely sure if this is what I'm after since I'll know ahead of time what signals I want to interact with, I just don't want to constrain their size. But I am certainly interested in your patch. Are you also looking to push it upstream?

RE: Verilator signal reflection? - Added by Jie Xu over 4 years ago

You can find the patch here in vardbg branch.

Answers to your questions:
  • we have more control and info of the signal using the vardbg than --public. --public exports things directly to the C++ domain where dbgvar patch still maintains them in the Verilator scope.
  • Yes
  • We currently only enable this patch in debug mode, we don't really care about the performance of this yet.