Add RFC for structured VCD output

[eigenform]

Rendered

[whitequark]

Thank you, this is very well written! My comments:

• Some examples of how the UI of GTKWave and Surfer will look like afterwards would be very helpful. (I think there are already RFCs which include media to use as an example.)
• An alternative is to keep the ability to use both formats, via the use of an environment variable (which is useful if you want to upgrade a third party codebase without modifying it, in possibly many places) and/or a parameter to write_vcd().

(Edit: I now noticed the "Does this feature need to be gated/opt-in by default?" unresolved question, which would cover my second comment.)

[whitequark]

One reason to use pyvcd (VCD itself is not hard to emit) is its support for .gtkw files. I really don't want to have more GTKWave specific code in Amaranth...

[whitequark]

Thinking about it, I feel that a prototype for this functionality would be not too difficult to build (you could depend on a git repo with a fork of pyvcd) and it would allow everyone impacted by the change to evaluate how it'll affect their workflow.

One consumer with little support for advanced VCD features that we need to care about is the Amaranth playground.

[whitequark]

I closed the PR accidentally (Shift+Enter), apologies!

[whitequark]

We have discussed this RFC on the 2025-05-12 meeting. The dispositon was to merge. The unresolved questions were approached as follows:

1. We should continue to have a "flattened" representation because, if nothing else, data.Layout permits having bits that are not a part of any field. Such bits would be completely invisible otherwise.
2. We should make this feature opt-out, both with a write_vcd argument and an environment variable. We will not port it to 0.5.x series.
3. We should work with pyvcd upstream to add these types; it is not reasonably expected to be a problem. (Pyvcd is a non-exposed implementation detail that isn't, in principle, a part of the RFC in first place.)
4. The Amaranth playground already has issues with structured data. It uses a library d3-wave that has "custom row renderers" that can be used to extend it in an application using it. We should update the playground code to emit custom row rendereds for structures (actually, we should've done it a while ago since right now strings don't display properly; Waveform renderer disappears for FSM signals and string reprs playground#2).

The next steps would be:

1. To update the RFC text with the information above so it can be merged. (this is on @eigenform)
2. To merge it and open a tracking issue for it in the main repo. (this is on me)
3. To implement and ship it. (this is on @eigenform or anyone else interested)

[whitequark]

Tracking issue opened: amaranth-lang/amaranth#1599. Can you add that to the body please? Along with start date.

[whitequark]

Thank you for writing and updating the RFC!