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

VCD Filter Files #1303

Closed
veripoolbot opened this issue Apr 18, 2018 · 7 comments
Closed

VCD Filter Files #1303

veripoolbot opened this issue Apr 18, 2018 · 7 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Apr 18, 2018


Author Name: Stefan Wallentowitz (@wallento)
Original Redmine Issue: 1303 from https://www.veripool.org

Original Assignee: Stefan Wallentowitz (@wallento)


Hi,

what recently bothered me a lot was debugging my own state machines. Some of those grew incredibly large (~90 states) but I don't want to split them (simple protocol processing, each state is like a few simple statements).

I read a bit into gtkwave's capabilities and it seems to me that a solution in the vcd file is not really workable: The only good one I can see is using wider fields and code the state as ASCII into them. But the changes in Verilator would be massive it seems (starting in the parser, ending in the runtime). Also the size of vcd files would not benefit from that..

So what I found a workable solution is to write filter files and assign them to signals in gtkwave. Those filter files contain a mapping from the integer value to a string to be displayed.

What I have started working on is a function that emits "filter files" for all enums as some extra output emitted by Verilator on demand.

Is that something you would accept?

Cheers,
Stefan

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Apr 19, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-04-19T14:01:02Z


I'm open to such a patch, however it maybe more useful to write a new trace writer that uses the gtkwave format.

Also see verilog-mode's AUTOASCIIENUM for a different approach.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Apr 19, 2018


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2018-04-19T14:08:05Z


Hi Wilson,

thanks a lot. I will have a look at LXT2 trace writers too. My first implementation prototype works well on the Verilator side, but the automation of feeding filter/alias files into gtkwave is very limited.

A better out-of-box solution that integrates perfectly with gtkwave seems more promising.

Cheers,
Stefan

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Apr 19, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-04-19T14:15:08Z


Great. BTW I would suggest a hand written writer rather than the gtkwave-sources one for generic simulators, as VPI is way too slow. Dedicated code would then be closer to the existing vcd writing code. Also there's work towards multithreaded, so having Verilator's own writer will avoid setting back that direction.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Apr 19, 2018


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2018-04-19T19:02:47Z


Thanks, I assume you mean this vpi stuff under contrib. By the way I think I meant FST, just double checking with you. There is a bunch of stuff in fstapi.{c,h}, that I will have a look at. A lot of stuff seems a bit specific in there, but its at least a good start to understand the format.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Apr 19, 2018


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2018-04-19T19:05:58Z


Linking to my "hotfix" that implements the filter files as described above: wallento@9ae2709

It is pretty much tailored to my own use case, so no robustness guarantees. But maybe someone just lands here, looking for exactly that.

I will instead focus on creating a different writer.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented May 19, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-05-19T12:04:37Z


Note I'm currently sitting on the above mentioned patch, since it seems fairly one-user specific and something better (FST) might be coming. If there's other organizations that want it in the mainline, we can work towards merging it.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Aug 28, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-08-28T10:44:27Z


LXT2 format added in #�, so think this isn't needed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.