Re: [ng-spice-devel] ACS new code
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: