gEDA-dev: Newbie developer guidelines.

al davis ad136 at freeelectron.net
Tue May 1 17:07:43 EDT 2007


On Tuesday 24 April 2007 15:07, Sven Wilhelmsson wrote:
> On Tue, 2007-04-24 at 14:35 -0400, Stuart Brorson wrote:
> > 2.  Alternately, just choose a project you think you'd like
> > (for example implementing JFET models), make it work, and
> > then send Al the patches.
>
> Note that gnucap-2007-02-21 and later can run models from
> ngspice as plugins. I have tried the JFET model and it seems
> to work. Therefore the priority is lowered for the JFET model
> IMHO. (Maybe there are still reasons for doing it.  ??? )

Two reasons I can think of ....

Licensing ..  There is a need for a GPL jfet model that can be 
distributed by default with the core.  The Spice model is 
licensed under one of the many variants of the old Berkeley 
license which is not GPL compatible.  With plug-ins, the 
license incompatibility only means that the models must not be 
in the same tarball as the simulator core, and you can't 
legally distribute a static linked executable with code from 
mixed licenses.

Performance ...  The performance of native models is better than 
Spice models with the wrapper.  There is overhead in the 
wrapper.

Reasons not to do it ...

The way to do it that is consistent with old stuff is a ".model" 
file.  This format is being phased out in favor of Verilog-A, 
but the tools are not ready.

Users want standard models.  When you make a new implementation 
there will be subtle differences, making it deviate slightly 
from what users think is the standard.  This is why gnucap is 
moving to being able to use unmodified models from others, 
rather than having its own.

There are 3 (at least) jfet models now ..  one is in the 
spice3f5 models tarball, two are in the ngspice models tarball.  
The one in the spice3f5 models tarball is probably preferred 
because it is most standard.  There is another one in older 
versions of spice that I have not packaged yet.  This will 
probably be the "spice3c-models" tarball .. for those who need 
the exact bugs of the old models.


More information about the geda-dev mailing list