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

Query parameters in simulation run #1262

Closed
veripoolbot opened this issue Jan 13, 2018 · 4 comments
Closed

Query parameters in simulation run #1262

veripoolbot opened this issue Jan 13, 2018 · 4 comments
Labels
resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor


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

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2018-01-13T19:59:20Z


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,
Stefan

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2018-01-14T11:22:57Z


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,
Stefan

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-01-17T01:02:47Z


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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2018-01-17T08:26:07Z


Hi Wilson,

oh, you are absolutely right. Shame on me, I entirely forgot to think about DPI..
But at least I know some new corners of the Verilator code base now ;)

Thanks a lot, please close the issue.

Cheers,
Stefan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Development

No branches or pull requests

1 participant