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

Jump to bottom

Add support for additional simulators in --protect-lib #1517

Closed
veripoolbot opened this issue Sep 24, 2019 · 1 comment
Closed

Add support for additional simulators in --protect-lib #1517

veripoolbot opened this issue Sep 24, 2019 · 1 comment
Assignees
@toddstrader
Labels
area: portability Issue involves operating system/compiler portability effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 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: 1517 from https://www.veripool.org

Original Assignee: Todd Strader (@toddstrader)

So far XSim has been tested and works with a shared library. We need to determine what we need to be able to build libraries for the different simulators. Some things that are definitely come up are:

  • 32-bit vs 64-bit (at least some versions of ModelSim are still 32-bit)
  • C++ ABI (again, at least some versions of ModelSim use a fantastically old compiler)

Also, I'd like to determine if it's possible to give commercial simulators static libraries instead of shared libraries. If most/all require the latter, we may want to just give up on static libraries even though it's easier for Verilator. In that case, we could add a --dpi-library-path option like the commercial simulators have so users don't have to mess around with LD_LIBRARY_PATH.
@veripoolbot veripoolbot added area: portability Issue involves operating system/compiler portability effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 type: feature-non-IEEE Request to add new feature, outside IEEE 1800 labels Dec 22, 2019
@wsnyder
Copy link
Member

wsnyder commented May 27, 2023

Closing due to age; unlikely to get supported anytime soon, if someone wants to contribute a patch please reopen.

@wsnyder wsnyder closed this as completed May 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@toddstrader toddstrader

Labels
area: portability Issue involves operating system/compiler portability effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 type: feature-non-IEEE Request to add new feature, outside IEEE 1800
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@wsnyder @toddstrader @veripoolbot