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
Query parameters in simulation run #1262
Comments
Original Redmine Comment Hi, sorry, I just found that /* verilator public */ for a parameter should do the job, but I get a parser error with that. Let me check before finally closing the issue. Cheers, |
Original Redmine Comment Hi Wilson, sorry for the noise. First, I found that I used it at the wrong position obviously. Then it did not have an effect and I got a bit into the code. The problem is that the parameters are constant and end up in a generator variable. They are therefore dead very early (stage 11). They don't seem to have the public attribute set and I need to dig deeper into that. Anyhow, I am not sure if its worth the effort or should be solved less elegantly in my surrounding infrastructure. Putting it on hold and would be great to hear your opinion. Cheers, |
Original Redmine Comment In general I'd avoid public as it isn't simulator portable. The ideal performance-wise is perhaps to have verilog in an initial block call a DPI import passing the resulting parameter value. |
Original Redmine Comment Hi Wilson, oh, you are absolutely right. Shame on me, I entirely forgot to think about DPI.. Thanks a lot, please close the issue. Cheers, |
Author Name: Stefan Wallentowitz (@wallento)
Original Redmine Issue: 1262 from https://www.veripool.org
Original Assignee: Stefan Wallentowitz (@wallento)
Hi Wilson,
I want to access a Verilog parameter set during the verilator run with -G. The use case is that I replicate a module based on this parameter with a generate. Now at runtime I want to call a DPI function in those modules for each instantiated one, using svGetScopeFromName and svSetScope.
So the function I need is something like Verilated::parameterMap(). The only alternative seems to iterate over scopes gathered by scopeNameMap(), but that would require filtering out other scopes etc. A constructive approach seems more sensible, where I can generate the scope based on queried data.
What do you think?
I would be happy to implement it, if you think that is necessary too and after your guidance on function name etc.
Cheers,
Stefan
The text was updated successfully, but these errors were encountered: