Re: [ng-spice-devel] ACS new code


To ng-spice-devel@ieee.ing.uniroma1.it
From Al Davis <aldavis@ieee.org>
Date Wed, 14 Feb 2001 12:38:05 -0800
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <OJGODMKNIPGDOAAA@hotbot.com >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <OJGODMKNIPGDOAAA@hotbot.com >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

On Wed, 14 Feb 2001, GLAO S. Dezai wrote:
> Paolo suggested to move to ACS for the new simulator.

I like this one, but I made ACS, so of course I am biased.

> 1)What does it means ?
>    a)Building a new simulator with ACS as   basis 

Yes.  You want a NEW simulator, right?

>  but with a new name 

Yes.  The new name must reflect the group development, in the same 
way that "Al's Circuit Simulator" says that it is my work.

> new code organization, 

I think it is pretty well organized as it is.  It could benefit from 
the multiple directories, but that has been in my plans for a long 
time.  The file prefixes could easily map to directories.  It is flat 
only because of some lame development tools, particularly on MSDOS 
and VMS, years ago.  Certain parts should be libraries so they can be 
used elsewhere.

> new parser (according to the previous
> discussions on netlist issues),

The parser works really well.  I do not recommend changing it.  I 
recommend that other tools use the ACS parser library.

Although I still like the dot form I originally suggested, changing 
it to any form that has been discussed is trivial, and does not 
require a "new parser".

> b)Hacking ACS code as we did in ng-spice.

I think that's the idea.

> 2)we must better know what ACS is.
>  a)ACS code: Speed,Reliability and Robustness.
> Does the code has been tested on the standard Spice  benchmarks ?

When you see differences, it is more important to understand why, and 
what is required to make it better.  The apparent best choice for 
today may be the worst choice moving forward.

I have treated ACS primarily as a research tool.  Because of this, 
many features that are important to end users are missing.

On speed, reliability and robustness, depending on the benchmark, it 
could go either way.  In theory, there is no reason for Spice to be 
better than ACS other than features left out.  I suppose the reverse 
could also be considered to be true, but Spice has some architectural 
problems that get in the way moving forward.  Some architectural 
decisions in ACS do take a speed hit, but open up opportunities for 
other optimizations.

>  b)Portability ?

Either is OK here.  It is important that members of "the team" use a 
variety of systems to be sure it is portable going forward.  One 
thing I am saying here is that if your favorite system is Windows, or 
a Mac, please continue to use it.  You can help on the portability 
issue.

>  c)Compatibility with Spice3(results and commands)

I never liked the Spice3 command structure, or its output format.  I 
also never liked the checklist nature of the batch files, inherited 
from Spice2.  ACS is more interactive, and the batch mode is more 
script like.  I think this is an improvement.  A shell script command 
rearranger may be the best answer here.

> 3)How can we organize for such a task ?.

or any big development project.
1. Modularity.
2. Knowing what everyone is up to.
3. ......
(same for any project)

> 4) What is the target platform: Linux, Windows, Both ?.

... and whatever we might get in the future.  It should be portable, 
standard C++.  Graphics should be external.  If someone wants to work 
on a graphic front end, that's great, but it shoule be a separate 
executable that runs the text mode simulator in a client-server 
relationship.


> 5)...
> ==========================================
> I have a good opinion about ACS because it is written in C++. I
> found ACS when trying myself to rewrite spice3 in C++, two years
> ago.


> I have not been able to compile it under my Microsoft Visual
> C++ 4.0 compiler. 

It doesn't.  MSVC 4 does not implement the full language.  I believe 
version 6 works.

> But i think it should be less buggy than the
> spice3f5 code. 

Wishful thinking.  It hasn't been beat on nearly as much.

But is it faster ? I

Looking to the future, probably.  Today, sometimes yes, sometimes no. 
 It depends on what you are doing, and what tradeoffs you make.

>   ... Finaly if we have to move to ACS, then  a better
> organization must take place for such a job. I suggest an
> organization by topics with a todo list by topic a moderator by
> topic and a devellopement list by topic. Topics could be 1. Testing
> and benchmarks
> 2. Analysis
> 3. Math package
> 4. Models
> 5. Frontend (GUI)
>    5.1 Entry (schematic editor, text editor)
>    5.2 Parser
> 6. Documentation

That needs to be done anyway.

For a Free software project, everyone needs to realize the variety of 
reasons why someone might want to work on it.  All involved want it 
to be well organized, but I don't think anyone wants the hierarchy of 
command that you get in a commercial development environment.

> Other suggestions
>  .Target Both Linux and Windows.
>    (Cross platform compilation ? Qt? UWIN? CYGWIN?)

"why I don't like autoconf......"

>  .Not keep al ".dot" format but choose between alan or paolo
> format. Let ".dot" format for commands and everything else for
> devices \resistance or #resistance or 5%#%5%%#%resistance :-)

I still like the dot.  It is a one character edit to change it to 
anything else.

al.


Partial thread listing: