Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more granularity to VCD export #674

Open
jeremyherbert opened this issue Jan 3, 2022 · 2 comments
Open

Add more granularity to VCD export #674

jeremyherbert opened this issue Jan 3, 2022 · 2 comments
Labels

Comments

@jeremyherbert
Copy link

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
Copy link
Contributor

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: #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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants