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

Protect against --protect-lib Verilator runtime incompatibility #1518

Closed
veripoolbot opened this issue Sep 24, 2019 · 2 comments
Closed

Protect against --protect-lib Verilator runtime incompatibility #1518

veripoolbot opened this issue Sep 24, 2019 · 2 comments
Assignees
Labels
area: configure/compiling Issue involves configuring or compilating Verilator itself area: usability Issue involves general usability effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800

Comments

@veripoolbot
Copy link
Contributor


Author Name: Todd Strader (@toddstrader)
Original Redmine Issue: 1518 from https://www.veripool.org

Original Assignee: Todd Strader (@toddstrader)


Currently all --dpi-protect'ed modules and the top-level design share the same Verilator runtime symbols. Some options which have been suggested so far are:

  • Wrap the --dpi-protect'ed modules' runtimes in a unique namespace
  • Maintain a relatively stable and versioned Verilator API
@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-09-24T12:16:08Z


Some items such as the mutexes for multithreading, tracing, VPI name lookup, and coverage are assumed to be common across all Verilated models. Perhaps some can be eliminated but probably not - for example there are only a certain number of physical CPUs so scheduling on more that that will tank performance. Some thought is needed on these.

@veripoolbot veripoolbot added area: configure/compiling Issue involves configuring or compilating Verilator itself area: usability Issue involves general usability effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800 labels Dec 22, 2019
@wsnyder
Copy link
Member

wsnyder commented Nov 28, 2021

I think #2359 can remain discussing this, so this one #1518 can be closed as duplication.

@wsnyder wsnyder closed this as completed Nov 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: configure/compiling Issue involves configuring or compilating Verilator itself area: usability Issue involves general usability effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800
Projects
None yet
Development

No branches or pull requests

3 participants