Debug with waveform GUI

[bpadalino]

I am used to debugging my VHDL with some type of waveform GUI - usually with Questa/ModelSIM or Riviera-PRO. This allows me to look at locals over time and do some other inspection with quick iteration on items I may have missed deep down in some design hierarchy.

With that being said, I think adding a full GUI to nvc is a terrible idea. This leads me to ask the question: how do other users use simulators with GUIs? Do you miss it with nvc? If nvc had a GUI front end similar to gdbgui would you use it, or would you stick with self-checking testbenching and not use the GUI aspect?

[Blebowski]

Hi @bpadalino,

I think having GUI is crucial for good usability of a simulator. Self-checking test-bench does not really help, when one needs to debug test failure. In such case, GUI that shows hierarchy, has good UI, is fast and responsive, provides schematic viewer, stepping, breakpoints, etc, is needed.

Gtkwave is good tool (cudos to Tony Bybell), but unable to match capabilities of tools like Verdi or Simvision. For the past half-year,
I am playing with the idea to start "HW debugger" project based on Qt, that could be used as waveform / schematic / hierarchy tracer.
I think a debugger can be separated from the simulator, and inspect the objects in simulation via VPI/VHPI (I know that is the way
commercial tools do it). However, I have a full time job with huge workload, so I don't think I have time to start writing such tool.
Maybe in couple of years. Plus, the effort to write such tool is enormous, good discussion about this is at:
gtkwave/gtkwave#140

[nickg]

An alternative might be to build the UI as a web app in the browser. The simulator would expose a simple HTTP API on localhost and then the UI would be written in HTML/JavaScript and send requests to that. Similar to how Jupyter Notebook works. Any high-performance parts like the waveform display could be written in Rust (or another language) and compiled to WebAssembly. IMO this has a much lower barrier to entry for potential contributors than C++/Qt and is a more "modern" stack so there's a wider choice of toolkits, etc. but it's still an awful lot of work.

[nickg]

An alternative might be to build the UI as a web app in the browser. The simulator would expose a simple HTTP API on localhost and then the UI would be written in HTML/JavaScript and send requests to that.

I've been experimenting with this idea for the past six months or so and just pushed a prototype to the master branch in d143c1a. The simulator exposes a WebSocket interface that a client can connect to and send TCL commands and receive events back ("next time step", "signal value changed", etc.). On top of that is a browser-based app in contrib/gui which renders waveforms and provides a console to interact with the TCL shell. Currently it looks like this:

If you want to try it out run configure with the new --enable-gui option and then do make and make install. The install step is important as the static HTML/JS/CSS assets are served out of the install directory. There is a dependency on NodeJS and NPM which you can install from the OS repository (e.g. apt-get install nodejs npm).

Once installed you can run nvc -e toplevel --gui to elaborate toplevel and then start the GUI server. Then open a web browser and connect to http://127.0.0.1:8888. You can also pass TCL commands to be executed immediately with the --init= option. I normally do something like nvc -e toplevel --gui --init="add wave -r /*; run 1 us".

Note: Windows support is broken at the moment. I need to debug this.

It's written using TypeScript and React. I hardly know anything about web/UI development but I was able to hack this together after watching a few YouTube tutorials and copious amounts of searching on Stack Overflow. It's certainly a much more pleasant experience than when I've tried native UI development with Gtk/Qt in the past. The waveform view is actually just a giant SVG, with some optimisations to lazily render only what is currently visible. If you want to try modifying it there's some hints in contrib/gui/README.md.

Obviously is just a demo and not ready for real use yet but any comments or feedback would be greatly appreciated.

[nickg]

According to Google that error might be to do with Windows blocking certain ports. Apparently netsh interface ipv4 show excludedportrange protocol=tcp will reveal which ones are unavailable (at the moment it's hard-coded to use 8888).

[avelure]

Ah, yes that's it. There is a bunch of blocked ports and 8888 is in one of the ranges.
It seems like too many ports are set as dynamic port ranges in the windows NAT, possibly due to a win bug docker/for-win#3171 (comment)

Changing the hardcoded value in the source to one that is available I now get
E: fread: C:\msys64\clang64\share\nvc/gui/index.html: No such file or directory
Which I guess is a problem of normalizing the path separators, as the file is there.
It is the same from native cmd and from within msys64.

[nickg]

Changing the hardcoded value in the source to one that is available I now get E: fread: C:\msys64\clang64\share\nvc/gui/index.html: No such file or directory Which I guess is a problem of normalizing the path separators, as the file is there. It is the same from native cmd and from within msys64.

Windows usually accepts mixed / and \ in a path though. The error actually occurs when reading the file which makes me think it might be a line-ending issue as the file was opened in text mode. I've switched to to binary mode, could you try again? I also added a --port=NNN option to the --gui command so you can change the port number.

[avelure]

We get a bit further, I get the "Example panel" and the wave view, but then there is an exception without a traceback.

* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x7ff67a1d619e: Access violation writing location 0xd646d407
    frame #0: 0x00007ff67a1d619e nvc.exe`jit_try_vcall [inlined] jit_transition(j=0x0000000000000000, from=JIT_RUNNING, to=JIT_IDLE) at jit-core.c:622:18
   619        fatal_trace("expected thread state %d but have %d", from, thread->state);
   620  #endif
   621
-> 622     thread->state = to;
   623
   624     switch (to) {
   625     case JIT_RUNNING:
(lldb) bt
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x7ff67a1d619e: Access violation writing location 0xd646d407
  * frame #0: 0x00007ff67a1d619e nvc.exe`jit_try_vcall [inlined] jit_transition(j=0x0000000000000000, from=JIT_RUNNING, to=JIT_IDLE) at jit-core.c:622:18
    frame #1: 0x00007ff67a1d6192 nvc.exe`jit_try_vcall(j=0x0000000000000000, f=0x0000000000000000, result=0x0000020930722430, args=0x000002093fcabeb0, tlab=<unavailable>) at jit-core.c:661:7

[nickg]

I created issue #796 for this.

[cmarqu]

Related: https://github.com/wavedrom/doppler (used in https://github.com/wavedrom/vcdrom which in turn has clickable examples in https://github.com/wavedrom/vcd-samples#github). Maybe it could save some work.

[nickg]

Thanks, I'd seen wavedrom before but not this dynamic version.

[Blebowski]

Hi,
I have recently came to a project that might be of use here:
surfer

Its written in rust, and it seems ti can be compiled stand-alone and into a web-browser too.
Already supports FST, and VCD. Seems to be new and under very active development.