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

Support optional nonfree Verilog-A models #2

Open
5 of 15 tasks
guitorri opened this issue Nov 22, 2016 · 2 comments
Open
5 of 15 tasks

Support optional nonfree Verilog-A models #2

guitorri opened this issue Nov 22, 2016 · 2 comments

Comments

@guitorri
Copy link
Member

guitorri commented Nov 22, 2016

Objective: bringing back the non-free model user experience, as an optional extension to QUCS.

on the QUCS end

  • implement dynamic loader (dlopen)
  • implement a dictionary for components
  • make components dynamic, so more can be added with dlopen
  • automatically load (some/selected) installed extensions
  • cleanup the rest of the code, to behave (exactly) as previously
  • provide makefile for symbol module compilation

this repository

  • create a stub device for testing (47d5e4a)
  • import verilog code that works with qucs
  • build/install the components for the gui
  • provide binary plugins for qucsator

qucsator

  • implement dynamic loader (dlopen)
  • simplify model compilation (revisit makefiles)
  • maybe some minor path issues
  • implement command to build model extentions (.hdl or similar)
  • implement command to handle model cards (.modelcard, .include or similar)
@felix-salfelder
Copy link
Member

the essentials of the symbol plugins are working (in the component_modules) branch.

you can now do qucs -a mymodules, and get the modules from mymodules.so listed in the toolbox. see the resistor for an example. will figure out more of the details...

the idea here is to turn the nonfree modules into nonfree-modules.so ...

@felix-salfelder
Copy link
Member

new idea, question, remark.

the first goal of this endeavour is to reenable the removed functionality. it will be much easier, to put the gui-symbols into qucs/contrib/legacy_va_symbols (is there anything non-free about them?). this will facilitate the gui-symbol-interface development in the early phase. also it will enable us to focus on the final we-attach-custom-models-and-symbols, rather than reimplement legacy functionality from the outside.

tl;dr; put the nonfree va code here. and put the old symbols/graphics into the gui repo, to be loaded optionally.

what do you think?

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

No branches or pull requests

2 participants