Re: gEDA-user: Re: change from ngspice to gnucap

[sdb@xxxxxxxxxx (Stuart Brorson)]

Umm, perhaps I was misunderstood.  Perhaps I wrote unclearly.  Or
perhaps people are in the mood to pontificate today.

As Dan pointed out, I think you should use gschem -> gnetlist -g
spice-sdb -> ngspice/gnucap as your analog simulation flow.  I think
you should invoke the programs from the command line.  The command
line is not difficult, and knowing the commands used to invoke the
tools will help you when you get to teh point of writing Makefiles to
automate your design flow.

OTOH, I don't think you should create netlists or schematics using a
text editor.  I can't imagine any reason to do so, unless you want to
create a 3 part knock-off netlist for a quick SPICE run.

Stuart






> 
> On Thursday 20 April 2006 16:59, Stuart Brorson wrote:
> > However, I do agree with the other posters who said that you should
> > get used to the command line, since when you become more advanced you
> > will find that it is much more powerful than using a point-and-drool
> > interface. =A0Using Makefiles to automate building your project is just
> > one such example of the power of unix's command line.
> 
> You are right when you say that the command line is more powerful than any=
> =20
> GUI, but then, why do you care to use a graphics tool to capture your=20
> schematics? You can write your netlists perfectly with ed, sed or vi? Could=
> =20
> it be that it is easier for the human brain to manage something that is=20
> graphich than something which is textual?
> 
> The real problem is that as soon as you are able to program such tools, you=
> =20
> are also able to manage Makefiles and then your personal need for such a GU=
> I=20
> tool is eliminated, and since you don't earn money on writing open-source=20
> software you don't waste time writing tools /you/ don't need. It's a dog=20
> bites tail thing.
> 
> Even billion dollar tool creators like Cadence don't manage to make simulat=
> ion=20
> front-ends which really help the designers. A simulator front-end does not=
> =20
> need to be fancy, but it has to support a lot of simulator options. And sin=
> ce=20
> there are at least  more than two simulators, you would have to make the=20
> front-end modular to support whatever the end-user like to use. And that's=
> =20
> when the fun stops.
> 
> Even if nobody are going to write any of these tools, it would be nice to h=
> ave=20
> a collection of the features that users would like to see. If the=20
> specification for such a program would be there it is easier to start from=
> =20
> somewhere.=20
> =2D-=20
> Svenn
>