GTKW files with signal groups

[tilk]

For debugging complex circuits, it's useful to have the signal traces grouped according to their function. The popular gtkwave tool supports this, as does the GTKWSave class from the vcd package used by Amaranth to export VCD files. All that remains is to connect this together.

I have implemented an extension to Amaranth's _VCDWriter which does just that. The idea is that the traces argument can be passed other things than lists of signals. My implementation currently accepts the following as traces:

• Signals, which work as before.
• Iterables (e.g. lists) of traces, which shows them in gtkwave one after the other, like before.
• Mappings (e.g. dicts) of traces, which create a new group of traces for each item in the mapping,
• Amaranth Records, which group the fields of the record.

There is no support in the current implementation for the recently added lib.data classes from RFC 1, but it can be easily added.

Are you interested in merging this functionality to Amaranth?

[whitequark]

Let's discuss improvements to VCD and GTKW writing functionality after the next release.

[whitequark]

I'm interested in expanding traces= handling with the following behavior:

• dict: creates a group per dict key.
• list or tuple: expands into individual elements recursively.
• data.View: expands into a group with individual parts, unless a single field, in which case the group is omitted.
• MemoryData: expands into all rows of the memory (requires Add MemoryData; like Signal but for memories #1221).
• wiring interface objects: expands into a group with individual signals recursively.

Note that I've specified dict and list above because I consider the syntax of tracing to be a mini-DSL where I ascribe new meaning to, specifically, the Python {} and []/() syntax. This allows flexibility for later expansion with other objects, which may also be e.g. iterables.

Is this something you're interested in implementing? I'd be happy to merge that in 0.5, but otherwise I may have to bump it to 0.6.

[tilk]

I could port the implementation of this feature from Coreblocks, adapting the behavior to stated requirements.

[whitequark]

Sounds good to me.

[tilk]

It looks like there is a regression on #790: I can't get view field traces on main. I will try to do a bisect later.

[tilk]

I bisected the regression to commit 2bf1b4d.

[wanda-phi]

Yeah, I see the problem, I'm going to do a quick fix soon

[wanda-phi]

Fixed in #1237.