repository for models

[felix-salfelder]

since the non-free and GPL incompatible stuff has been removed from the qucs main repo, there seem to be ongoing complaints on qucs not running some transistor models.

we should either fix/complete the adms templates used for the qucsator frontend (anyone?!). or (temporarily) provide the modified models somehow. i propose to create a repo "models-nonfree" within the qucs project for holding those models. i already proposed this a year ago and i proposed this in a private email thread.

now, lets discuss in public. or just create that repo? any opinions?

[ra3xdh]

Yes, something like qucs-nonfree repository looks a good temporary solution. Linux distributions faces similar problems with firmwares, codecs, etc. Some of them uses such approach, if other solutions are impossible.

[felix-salfelder]

go for it!

NB: i don't see the "temporary" aspect of that approach. in gnucap we have repositories with that kind of stuff for 10+ years. you (basically) just type $ make install and then you can invoke gnucap with $ gnucap -a nonfreemodel.so. we also use this to drop-in substitute built-in components and models...

[guitorri]

https://github.com/Qucs/qucs-nonfree

I wish we could offer the original models (the ones that allow redistribution) and patches, or just patches.

Any ideas for the directory structure?

I have somewhere a bit of code that writes the symbol to file, so we can roll back to 0.0.18 fetch the models and the symbol from the C++.

[felix-salfelder]

I wish we could offer the original models

let's include them (any reason not to?)

how about orig file+patch and a Makefile that applies the patch?

Any ideas for the directory structure?

i do not have a preference. the important part is, what make install will produce.

lets just collect the models first! who has access some of them (i mean, the unpatched vanilla and current upstream version...)

[guitorri]

I had the BSIM6 lined up in #322 but will have to wait for a cherry-pick, we are not including it anymore.

Something like this apply_patches.sh might be helpful. Perhaps a plain makefile would be better? Users will need a make and a compiler toolchain anyway. Perhaps it makes sense to add the models inside a test_prj, so people can have the original, the patches and the patched versions.

I think we can start with hicumL2V2p31n.va, it is the latest version we have in 0.0.18: https://github.com/Qucs/qucs/tree/qucs-0.0.18/qucs-core/src/components/verilog

The original has just a few lines of difference, available at: https://www.iee.et.tu-dresden.de/iee/eb/hic_new/hic_source.html

With that the authors of HICUM can hopefully work with us with the newer models.

Felix, is it so that you you want to make install the loadable modules? I am afraid at the moment it the loadable modules are tied to the project directory.

[felix-salfelder]

thanks guilherme!

I am afraid at the moment it the loadable modules are tied to the project directory.

i am aware that currently this will not plain "work". however i'd like to have the models somewhere, so they can be tinkered with. and we get a better view on what patches are required for qucs-admsxml to work.

what we need is the symbols on the gui end and the models in the simulator end. as a temporary solution we should have 'make install' install the model binaries (if this is possible without linking). in the long run, the symbols should only (have to) point to the .va files (or contain whichever sort of reference to the .va code) and the compilation must take place on the simulator end, when needed (well, that step will be simulator dependent anyway...)

(as i mentioned, i am working on that, see the various PRs).

[felix-salfelder]

hmm, i can't seem to open PRs to qucs-nonfree, because it's an empty repo. and i cant push an initial commit, due to permissions...

help?

[guitorri]

I pushed an initial commit and gave you access to the repo as a collaborator. Let me know if something is not working.