[ng-spice-devel] a bit more
Some opinion about licensing and surroundings having
been explained, I foster as licensing policy for ng-spice
something like the one applied to PHP by the PHP Development Team.
(see http://www.php.net/license.html)
I believe is the best we could do for NGSpice, provided to have
a working code first and the possibility to merge Berkeley code
under other licenses, as well.
BTW, I agree with the considerations from Stephen Tell.
In the letter to Berkeley we should add that we're interested in
the models because they are the most significant contribution
made by the spice team.
We should acknowledge the contributions of Spice3 and the
University of California at Berkeley in the NG-Spice
documentation anyway.
We should maintain only one development tree.
Please Stephen, help us with your editing pass at the letter text,
its your mother tongue and you are welcome.
Kev, who is relocated to Silicon Valley, offered a "local" help.
I think is invaluable so you are welcome too, and every
happiness for your new location.
Now, a bit more on the technical ideas I've posted to
the develop mailing list.
Talking about Dynamic Shared Object in order to grant
the possibility to define extensions or include models with their
own methods without having to rebuild spice at all, just using a
run time inclusions defined in a configuration script file.
One other kind of implementation is like the one adopted by
Matlab m-files, though they are text files the gist is that
function structure, function code, and its help are defined within
the same module: the m-file.
In other words models structure definition, its own algorithms,
and help if required, could constitute a single run-time module.
With regards to models, what I mean in this context is not the model
as a list of parameters. I'm looking at the model topology or structure
as it vary model by model or with new model development as
technology files.
Therefor in a single module I would define the model parameter list
structure as a reference for the spice core module, which implement
common futures and functions, as well as model specific functions
not covered within the core module because specific to the model itself.
The help text then is a gadget and could be the beginning portion
of the parameter list file which is a text file and could be updated easily.
As a new model structure arise to cover specific needs or r&d
improvements a new module could be defined and included at run time.
Also there could be a way to formally define the module by the use of
pre-coded building blocks, obtaining the relative working code by the
use of a development tool that I call module-compiler.
This module-compiler could work something like visual C++ tools
or better lex and yacc, mind you visual capabilities are not required,
everything could be done with text file containing formal definitions.
Once made as fastest as possible the model run time module
your effort is only concerned with the actual parameters to be
declared in the parameter list file, the text file!
Bye now
franz
Partial thread listing:
- [ng-spice-devel] a bit more, (continued)
Letter to Prof. Vincentelli Draft 2
Paolo Nenzi