Tracking Signal Change Triggers in Verilator

[ThePerfectComputer]

Some visualization tools like the one in Model Sim allow you to get a trace on what conditions triggered the signal's change. How hard would it be to modify Verilator so that I could ask it what line(s) of Verilog caused my signal to change during a particular cycle?

[wsnyder]

This is a significant change that affects a lot of areas.

Also I don't believe it can be represented in any of the open source trace formats, so that would be the first upstream problem to solve before looking at Verilator.

Perhaps as a first step get a format to support it, and feed in a static list of all possible drivers for each signal? Then dynamic next?

[ThePerfectComputer]

I think it would make more sense to start from Verilator's end - that is, as progress is made implementing the feature in Verilator, a sensible format and or query API would naturally emerge.

I think the approach of "I hand Verilator a simulation trace such as a VCD and the original Verilog and ask it what caused this signal to change at time X" is probably the most portable approach. It's OK if it takes a bit for Verilator to solve this - maybe a second or two. In reality when debugging simulations, the engineer can only think so fast and I doubt the engineer would need to make more than one query every few seconds.

[wsnyder]

I personally would be reluctant to use a viewer which had more than a typical user-interface delay in any operation, around 100 msec. Also I don't see how to technically query Verilator for this information, it would need to store the information in memory, which would be memory prohibitive - much better to just store on disk with the trace.

Verilator doesn't "own" the trace formats. Perhaps see if GTKwave would accept an API pull to add this?

As to Verilator dumping, if we get the GTKwave agreement, and we're willing to just dump all active drivers on the given signal/member (versus bit-by-bit) this might be doable.