gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] readline support in interactive mode & ngSpice


From: Al Davis
Subject: Re: [Gnucap-devel] readline support in interactive mode & ngSpice
Date: Sun, 7 Apr 2002 21:49:08 -0700

On Friday 05 April 2002 14:25, Nuno Miguel Fernandes Sucena Almeida 
wrote:
> Hello,
>       i haven't looked at the gnucap code but i think readline support
> with automatic completion of command and device name would be nice.
> I'm willing to make it myself but i decided to ask first if you
> have any comments on that :)

That's great.  Thank you.  Readline is nice, but I have not had the 
time to do it.

>       in the other side of the spectrum, is there any relation between
> gnucap and ngSpice in such a way as sharing code/resources ? i
> think it would be nice too but about 1 year ago the ngSpice
> developers where strugling with the spice license...

There is more sharing than might appear on the surface.  For one, 
there is a considerable overlap in the subscribers to the developer 
lists.  Some of the key people in both subscribe to both lists.

Since you asked, I will give you a few comments on my feelings on the 
two projects and how they relate to each other.

First, here is my impression of what NG-Spice really is.  

Spice was an academic project many years ago.  Spice-3 was a rewrite 
with no new technology about 15 years ago.  Thus, it is basically 15 
year old technology.  Since then, it has been forked many times, with 
some incremental development in each fork.  Some of the forks are 
commercial.  Some are academic.  Unfortunately, these academic forks 
each went their own way, and in all cases development ceased when 
someone graduated.  They never got merged into the mainstream.  In 
effect, they have almost been lost.

NG-Spice could be thought of as another fork, but it isn't.  I think 
of it more as a reverse fork.  The NG-Spice team is taking these many 
academic forks and merging them back into a single unit.  From this 
view, it has great value and I hope it continues.  I also hope for 
some of the work to apply to Gnucap, too.  Maybe even the same people 
can do it.  I would really like to see a port of the Gnucap model 
compiler to NG-Spice!  Then we could share models.

One thing NG-Spice isn't is state of the art.  It will never be as 
long as it is based on Spice-3.  There is too much old baggage there 
to really move forward.

If you look at the technical leaders in commercial simulators, you 
will see that they are NOT Spice based.  The market leaders may be 
but the technical leaders are not.  There are some that exploit 
hierarchy, mixed signal simulators, interconnect focused, full field 
simulators, timing simulators, ...

To move forward requires a complete rewrite.  This is where Gnucap 
comes in.  It is not ready for the mainstream yet (hence the 0.xx 
version number) but it is getting closer.  It was designed from the 
ground up to support mixed algorithms, hierarchy, latency, dormancy, 
...   I want Gnucap to develop into the most advanced simulator 
available.

The down side is the a lot of code needs to be rewritten.  Spice 
model code is not compatible with Gnucap.  Acutally, there is a quick 
hack that would work, but you would lose the benefits of the advanced 
algorithms.  The biggest problem is untangling the Spice code.

The NG-Spice web page actually refers to two simulators.  First, 
there is the one that is we have now.  Second, it mentions a future 
simulator that will be all new, and licensed GPL.  I offered ACS 
(predecessor to Gnucap) as that new simulator, and it prompted some 
interesting discussions, but the work of that group remains focussed 
on the old one.  I think both groups would benefit if it is 
officially recognized that Gnucap is that new simulator.  The same 
"company" is continuing to maintain the old one, while developing the 
new one, recognizing that it will be a couple of years before the new 
one is really ready for the mainstream, and that collecting of the 
forks benefits the new one, too.

Of the individual developers, some will choose the traditional 
(NG-Spice), and some will choose the more experimental (Gnucap).  
Some will do both.  (Install a model written for Spice into NG-Spice 
then port it to Gnucap, or make a front-end or back-end that works 
with both.)

On the spice license ...   Of those in the NG-Spice group, some wish 
they could change it, some like it as it is.  Some are only there 
because of the license.  It is not just the Berkeley code.  Remember, 
it is the merger of several forks, with many owners.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]