8000 Add `--trace-saif` for SAIF power traces by magancarz · Pull Request #5812 · verilator/verilator · GitHub
[go: up one dir, main page]

Skip to content

Add --trace-saif for SAIF power traces #5812

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

Merged
merged 175 commits into from
Mar 7, 2025
Merged

Conversation

magancarz
Copy link
Contributor

This PR adds the possibility of dumping SAIF files (see Annex I) with --trace-saif flag, which can further be used as an input for design static power analysis in tools like OpenSTA. Example workflow of this process can be found here.

SAIF has an advantage over VCD format in terms of file size - SAIF trace saves accumulated statistics accumulated of signals in the form of their toggle count and time when bit was low/high instead of every change that happened during the simulation trace.
While VCD files can easily grow to gigabytes in size, SAIF usually takes up kilobytes and does not grow with simulation time. This speeds up processing by power analysis tools.

@wsnyder
Copy link
Member
wsnyder commented Feb 28, 2025

Note also #5806 - it's worth thinking about if this dumping can work with the parallelism that @gezalore is proposing, and if any changes should be made now for forward compatibility with that.

Copy link
Member
@wsnyder wsnyder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent. First round suggestions below, I'll re-review again after these updates.

@wsnyder wsnyder changed the title SAIF support Add --trace-saif for SAIF power traces Feb 28, 2025
@wsnyder
Copy link
Member
wsnyder commented Mar 3, 2025

Note please merge in master to make sure you have the latest github actions correct.

@magancarz
Copy link
Contributor Author

Note also #5806 - it's worth thinking about if this dumping can work with the parallelism that @gezalore is proposing, and if any changes should be made now for forward compatibility with that.

I've looked into that PR and reorganized activity accumulation code as @gezalore suggested in #5812 (comment). To implement a similar multithreaded trace it should be a matter of creating more instances of VerilatedSaifActivityAccumulator class in VerilatedSaif constructor after checking if multithreaded trace is enabled (based on something like here

if (split()) {
) and proper variables will be accessed through index stored in VerilatedSaifBuffer trace buffer object when emitting variable changes. As I understood correctly, fidx argument in declare* functions is index value of which target file/accumulation object should receive this variable.

@wsnyder
Copy link
Member
wsnyder commented Mar 5, 2025

I think that's a reasonable way to extend it. Let me know when you think all your updates are otherwise done and I'll re-review.

@magancarz
Copy link
Contributor Author

I think that's a reasonable way to extend it. Let me know when you think all your updates are otherwise done and I'll re-review.

All changes suggested by review comments are done. It is ready for re-review.

@gezalore
Copy link
Member
gezalore commented Mar 5, 2025

As I understood correctly, fidx argument in declare* functions is index value of which target file/accumulation object should receive this variable.

True, but you can also map multiple fidx into the same file if you want.

All the tracing callbacks that are registered with a given fidx, will be called with a trace buffer created with the same fidx, and trace the variables declared with the same fidx, that's all there is to it.

@wsnyder
Copy link
Member
wsnyder commented Mar 6, 2025

The github actions were not run, can you getthem working?

We get email on every push and it's been a lot of mail. ;)

please debug and get it ready on a separate personal branch, and push to this branch only when tests passing and you think it is ready for final review, thanks.

@kbieganski
Copy link
Member
kbieganski commented Mar 6, 2025

Sorry about the spam.
This seems like a weird random failure unrelated to this PR. t_mailbox_class has nothing to do with traces. The CI passes on our fork. I get a segfault on this test locally on master (but only with --debug).
I'll bisect it.

Edit: This commit seems to introduce the bug. Opened a new issue for it: #5834

@magancarz
Copy link
Contributor Author

Sorry for the problem. Code is ready for final review as the bug causing CI to fail was fixed and all checks finished successfully.

@wsnyder wsnyder merged commit 9b4509f into verilator:master Mar 7, 2025
63 of 64 checks passed
@magancarz magancarz deleted the saif branch March 10, 2025 07:38
magancarz added a commit to antmicro/verilator that referenced this pull request Mar 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0