amaranth-lang / amaranth

A modern hardware definition language and toolchain based on Python
https://amaranth-lang.org/docs/amaranth/
BSD 2-Clause "Simplified" License
1.59k stars 174 forks source link

Add more granularity to VCD export #674

Open jeremyherbert opened 2 years ago

jeremyherbert commented 2 years ago

This is a feature request.

It would be useful to have a way to explicitly include/exclude traces which are written to the VCD dump. This already exists for the gtkw file, but for designs with lots of signals it would be helpful to be able to control this more finely.

The use cases are to make VCD files smaller and to make it easier to find signals in large designs.

I came across this because sigrok crashes with VCD files that contain strings from FSMs (bug filed here: https://sigrok.org/bugzilla/show_bug.cgi?id=1757 ). Right now I am using GTKWave to only re-export the traces I am interested in and drop the FSM states.

Lunaphied commented 2 years ago

This essentially requires designing a new API surface for effectively specifying these signals. The current functionality with GTKW files is not ideal but works better than nothing for specifying top-level module ports and is essentially a holdover from the past. To extend it to the VCD would require new API surface added to specify separately somehow the distinction between which traces are being dumped to the VCD and which are just being added to the GTKW.

There are various other examples that would benefit from explicitly attaching metadata of varying degrees to signals that has common meaning, one of which I view as important is eventually providing an implementation agnostic way of specifying signal attachments to a platform specific or generic implementation of an integrated logic analyzer.

This idea has been explored somewhat here: https://github.com/amaranth-lang/amaranth/pull/624, but this should likely be taken up as an RFC for further development.

In the meantime I suggest a simple local patch to achieve what you want. I believe modifying the code here to check if a signal was specified in the provided traces list before adding it should be enough to workaround this issue for now.

jeremyherbert commented 2 years ago

Thank you for the pointer, I will make a local adjustment for myself in the meantime.