Verilator Statistics-printing Survey
wsnyder opened this issue · 1 comments
Verilator is considering printed statistics to stdout. Please consider taking a brief survey on this topic. This survey will close February 29th.
Thanks for all that participated. After filtering out spam, here's the results:
Q1: Do you use --main and/or --binary when creating a model (ignore times when using --lint-only). You may select more than one.
- 21% I typically run Verilator underneath another framework, e.g. cocotb (and that framework makes the C++ main())
- 28% I typically use --main or --binary (and so Verilator makes the C++ main()).
- 50% I typically use neither --main nor --binary (and so always use my own C++ main()).
Q2: Should Verilator, when Verilating (--lint-only inclusive), print statistics to standard output, e.g. print a single-line summary of compile time, number of modules, memory usage, etc? (Currently, like GCC, Verilator doesn't print this information. It has --stats but that writes to a separate output file.)
- 16% I don't expect to use/want this output.
- 42% I'd like a Verilation-time summary, as an option I have to enable.
- 40% I'd like a Verilation-time summary, on by default, with an option to disable (e.g. --quiet).
Q3: Should Verilated models, when using --main/--build and so creating a main(), when the simulation finishes, print statistics to standard output. E.g. print a single line summary of simulation end time, wall time, memory usage, etc? (Currently Verilated models do not print this information.)
- 23% I don't use Verilator's main() and/or don't expect to use this runtime output information.
- 33% I'd like a runtime summary, as a runtime +veriltor+ option I have to enable.
- 42% I'd like a runtime summary, on by default, with a runtime option to disable (e.g. +verilator+quiet)
Some notable open responses:
- Changing defaults is fine
- Show CPU time, core count, thread count, memory usage
- Have a method for user's main() to also print these statistics
Some people commented on progress on UVM and other bugs. As always, progress depends on people contributing code ;)
I plan on accepting the majority, which want the summaries, and also will (eventually) implement most of the ideas expressed.
If you have other critical comments please post to verilator/verilator#4909; I'm closing this verilator-annouce issue to reduce mass mail.