HSpice to PSpice Library Converter Added to Webpage

[Jens Tingleff]

On 25 Sep 2003 22:57:26 GMT, "Mike Engelhardt" <[email protected]>
wrote:

Jim,

[snip]

Jim, I'd never accuse you of being a socialist, in fact, you'd
probably be an OK guy if you weren't so darn liberal. [..]
--Mike


Now *that's* a first. I've never been called a liberal before ;-)

ROTL!

Mike, in the US "liberal" means "communist."

Jim, in Europe, "liberal" means "fascist."

Cant say I agree with this in the slightest. The "Liberal" party in the
UK is neither, and I have never associated that word with anything like
the negatives that you suggest here.

Kevin,

1) Quite, so. I was using "Europe" where I should have used "continental
Europe". The Uk usage is indeed different from the continental usage. Somewhere
in between, I would say ;-)

2) As for the words I used, please insert ";-)" liberally (sorry!) into my
original message - if that makes it easier to accept. If not, don't.

Regards

Jens

Key ID 0x09723C12, [email protected]/[email protected]
Analogue filtering / HIPERLAN / Mdk Linux / odds and ends
http://www.imaginet.fr/~jensting/ +44 1223 211 585
"I don't think you *can* dig your way off a planet.." D Adams

 

[Mike Engelhardt]

Greg.

I personally haven't used LTSpice for one simple reason - Linear Tech
hasn't ported it to Linux. They could at least port their SPICE engine;
that shouldn't be difficult at all, unless it is hopelessly intertwined
with their GUI (which would be a hopelessly stupid mistake on their
part). A command-line driven engine for Linux would be perfectly fine
as far as I am concerned.

This is the relevant part of the FAQ from the
help system regarding Linux/WINE:

Q. Do you have a version of LTspice for Linux?
A. Not a separate edition, but it does run under
WINE. The program has been tested on Linux
RedHat 8.0 with WINE version 20030219.

Q. OK, I've never used WINE, how do I install that
on my Linux box?
A. 1. Check with www.winehq.com to find the current
version of WINE for your system. At the time
of this writing, for RedHat 8.0, this points
to http://mecano.gme.usherb.ca/~vberon/wine
2. Copy the appropriate .rpm file to your machine
and open it from nautilus.
3. Get the file swcadiii.exe from www.linear.com.
In an xterm, execute "wine swcadiii.exe" to
install LTspice.
4. There will now be a Linear Technology Logo on
your gnome desktop. Double click it to start
or type "wine scad3.exe" from an xterm to
start the program. That's it!

Q. The schematic fonts don't scale as smoothly under
WINE as Windows. Why is that?
A. WINE is doing the best best it can with the fonts
it finds. It will do better if you tell it how
to find the files arial.ttf and cour.ttf from
your Windows system.

Q. The PWL additional point editor doesn't look
right under WINE?
A. Try using the native Windows .dll from your
Windows system. The command line to then invoke
LTspice from WINE is:
wine -dll commctrl,comctl32=n scad3.exe.

Q. It seems LTspice is running slightly differently
under WINE/Linux than windows. Why is that?
A. LTspice detects whether or not it's running under
WINE. If so, it works around a few WINE issues.
You can force LTspice to think it's running under
WINE with the command line switch -wine. You can
force it to think it's not with the command line
switch -nowine in case you're interesting in
debugging WINE.

Q. Under Windows, LTspice extends the virtual
address space for waveform viewing to 64 bits.
Does that work under WINE?
A. Yes. It has been tested on waveform files over
5 Gigabytes in size.

Q. Under Linux, does it support unlimited component
count and depth of schematic hierarchy?
A. Yes. Opps, no. The maximum depth of hierarchy
is 64 levels but that limit is just there to
allow detection of infinite subcircuit recursion.
(Most "unlimited" SPICE's "limit" you to about 21
levels.) LTspice has no limit on node or
component count either per page or for the
entire circuit.

Q. Does cross-probing while simulation work with
those slick marching waveforms while running
under Linux?
A. Yes.

Q. So from what version on is LTspice supported
under WINE?
A. 2.01g.

--Mike

 

[Mike Engelhardt]

Mark,

...I've seen some very strange things with the proteus VSM simulator
I use. Besides the (all-too-frequent) convergence problems, I've
noticed that zener diodes do not like to bias like they should...

Make sure you specify Ibv. Berkeley SPICE defaults to 1mA but
PSpice(and LTspice) defaults to 1e-10A. I see more PSpice-targeted
models than Berkeley SPICE and this difference in anticipated
default breakdown current effectively moves the zener voltage on
unmodifed Berkeley sources. If you specify ibv, the model should
breakdown similarly on all SPICE's, though the exact breakdown
function used does differ between the PSpice and LTspice breakdown
vs the Berkeley SPICE in the interest of handling a discontinuity
in the Berkeley version.

--Mike

 

[Paul Burridge]

Jim,
[snip]

Jim, I'd never accuse you of being a socialist, in fact, you'd
probably be an OK guy if you weren't so darn liberal. But where is
your entrepreneurial spirit. Why would seat count interest me when
it's a free simulator? If I thought selling licenses was the
best means to develop the best SPICE program in the most
profitable manner, then I'd run the biggest EDA/software company
and do that.

--Mike

Now *that's* a first. I've never been called a liberal before

I nearly fainted at this point!
:-D

 

[Greg Pierce]

Greg.


This is the relevant part of the FAQ from the
help system regarding Linux/WINE:

<snip FAQ>

So, instead of having to run the substandard OS, I need only run an
interface layer for the substandard OS.. cool... now, is their a FAQ for
running it in batch mode?

 

[Russell Shaw]

Greg.



This is the relevant part of the FAQ from the
help system regarding Linux/WINE:

But it doesn't give anyone any warm fuzzies on linux
knowing they have to use something derived from a total
retard swiss cheez OS.

 

[Michael A. Terrell]

But it doesn't give anyone any warm fuzzies on linux
knowing they have to use something derived from a total
retard swiss cheez OS.

Then write your own software, and keep it strickly for Linux.

 

[Russell Shaw]

Then write your own software, and keep it strickly for Linux.

That's what i'm doing. It's not so hard to write a spice
from scratch. It takes more to figure out the parser and
lexical analyser tools/methods. The actual guts of most
numerical analysis programs is very easy. A lot of pictorial
imagination helps in devising new algorithms.

 

[Mike Engelhardt]

Greg,

<snip FAQ>

So, instead of having to run the substandard OS, I
need only run an interface layer for the substandard
OS.. cool... now, is their a FAQ for
running it in batch mode?

I think batch mode is mentioned in the help. I know
it's been documented a few times in the users'
group http://groups.yahoo.com/group/LTspice. Basically
you just do "scad3.exe -b file.cir" The data will be
in file.raw, and warnings, errors, and accounting
information will be in file.log. When you run the
LTspice executable in this manner, then it never
becomes a MS Windows program, i.e., it never creates
a window or starts the message pump.

But I recommend just running it under WINE. The
program is designed to work properly under WINE.
There's no speed/performance penalty for simulation.
There's a slight graphics speed penalty but, as
LTspice uses direct screen writes, most of that
penalty comes from the poorer graphics performance
of the X Windows System, not WINE.

However, the MS Windows help system doesn't work
under WINE, you can get a .pdf of the help from
http://LTspice.linear-tech.com/software/scad3.pdf.

--Mike

 

[Mike Engelhardt]

Russell,

But it doesn't give anyone any warm fuzzies on linux
knowing they have to use something derived from a total
retard swiss cheez OS.

You might try it before dwelling on OS flame war issues.
As I explained in my other post, there's no simulation
speed penalty. The only performance penalty deals
with the relatively poorer performance of X graphics
verses the simpler MS Windows graphics. BTW, I believe
LTspice is the only SPICE on Linux that uses a 64 bit
address space for waveform data on 32 bit processors.
The virtual memory extension I wrote for Windows was
also ported to Linux/WINE.

--Mike

 

[Steve Hamm]

That's what i'm doing. It's not so hard to write a spice
from scratch. It takes more to figure out the parser and
lexical analyser tools/methods. The actual guts of most
numerical analysis programs is very easy. A lot of pictorial
imagination helps in devising new algorithms.

Hmmm. I'm looking forward to seeing what you come up with. My guess is
that you don't have very much experience with circuit simulation if
you consider the parser more of a problem than solving nonlinear
equations, differential-algebraic equations, and sparse matrices...

--Steve

 

[Greg Pierce]

Greg,

But I recommend just running it under WINE. The
program is designed to work properly under WINE.
There's no speed/performance penalty for simulation.
There's a slight graphics speed penalty but, as
LTspice uses direct screen writes, most of that
penalty comes from the poorer graphics performance
of the X Windows System, not WINE.

Of course, the performance penalty wouldn't be there if it was using the
proper Xv calls and such ;-)

 

[Russell Shaw]

Hmmm. I'm looking forward to seeing what you come up with. My guess is
that you don't have very much experience with circuit simulation if
you consider the parser more of a problem than solving nonlinear
equations, differential-algebraic equations, and sparse matrices...

I've made optimizer programs that fit ladder LC filters and pulse
shaping filters to fit a goal pulse response, optimizers for
frequency and phase equalizers, etc. Also made curve fitting
programs to fit gummel-poon and mosfet spice model parameters
(DC and capacitance measurements).
To do that, i had to implement my own transistor models,
confirm that they agreed with pspice, then make the 4th-order
runge-kutta analysis program to calculate the DC response in
an assumed circuit. Goal convergence was done using mostly
steepest descent or conjugate gradient methods.
Spice literature is full of cruft on gaussian elimination
and sparse matrices. The first is easily eliminated due to
properties of the second. Ill conditioning is not in my
vocabulary. Numerical mathematics is a walk in the park.
However, spice clones are a low priority because with
enough experience you only need simulation to verify some
small circuit block you can't get grips of, or to verify
a mathematically intense design such as a filter. Other
areas of cad are more useful to me...

 

[Mark Jones]

Mark,


Make sure you specify Ibv. Berkeley SPICE defaults to 1mA but
PSpice(and LTspice) defaults to 1e-10A. I see more
PSpice-targeted models than Berkeley SPICE and this difference
in anticipated
default breakdown current effectively moves the zener voltage
on unmodifed Berkeley sources. If you specify ibv, the model
should breakdown similarly on all SPICE's, though the exact
breakdown function used does differ between the PSpice and
LTspice breakdown
vs the Berkeley SPICE in the interest of handling a
discontinuity
in the Berkeley version.

--Mike

Interesting, thanks for the heads-up.

 

[Stuart Brorson]

: Steve Hamm wrote:
:> On Sat, 27 Sep 2003 20:05:55 +1000, Russell Shaw
:>
:>>That's what i'm doing. It's not so hard to write a spice
:>>from scratch. It takes more to figure out the parser and
:>>lexical analyser tools/methods. The actual guts of most
:>>numerical analysis programs is very easy. A lot of pictorial
:>>imagination helps in devising new algorithms.
[ . . . . . . . .]
: Numerical mathematics is a walk in the park.
: However, spice clones are a low priority because with
: enough experience you only need simulation to verify some
: small circuit block you can't get grips of, or to verify
: a mathematically intense design such as a filter. Other
: areas of cad are more useful to me...

It sounds like you know something about numerical work, or at
least can spout the buzz-words correctly. Therefore my suggestion
would be to join one of the existing free-software projects like
tclspice, ngspice or Gnucap and help out with bringing those apps to
the next level instead of re-inventing the wheel.

<soapbox>

One problem with the free software world is that there is a propensity
amongst developers to start new projects rather than helping with
pre-existing ones. This may be due to hubris, lack of knowledge about
other projects, or something else. However, it leads to the problem
that there are lots of similar packages out there which implement
4/5ths of a task, but are never finished. (Of course, there are
plenty of wonderful -- fully featured -- free software projects too,
so don't assume that all are like that.) Since a couple of
fully-featured apps are better than lots of unfinished ones, why not
join a pre-existing project if you want to make a contribution?

</soapbox>

Stuart

 

[Russell Shaw]

: Steve Hamm wrote:
:> On Sat, 27 Sep 2003 20:05:55 +1000, Russell Shaw
:>
:>>That's what i'm doing. It's not so hard to write a spice
:>>from scratch. It takes more to figure out the parser and
:>>lexical analyser tools/methods. The actual guts of most
:>>numerical analysis programs is very easy. A lot of pictorial
:>>imagination helps in devising new algorithms.
[ . . . . . . . .]
: Numerical mathematics is a walk in the park.
: However, spice clones are a low priority because with
: enough experience you only need simulation to verify some
: small circuit block you can't get grips of, or to verify
: a mathematically intense design such as a filter. Other
: areas of cad are more useful to me...

It sounds like you know something about numerical work, or at
least can spout the buzz-words correctly. Therefore my suggestion
would be to join one of the existing free-software projects like
tclspice, ngspice or Gnucap and help out with bringing those apps to
the next level instead of re-inventing the wheel.

<soapbox>

One problem with the free software world is that there is a propensity
amongst developers to start new projects rather than helping with
pre-existing ones. This may be due to hubris, lack of knowledge about
other projects, or something else. However, it leads to the problem
that there are lots of similar packages out there which implement
4/5ths of a task, but are never finished. (Of course, there are
plenty of wonderful -- fully featured -- free software projects too,
so don't assume that all are like that.) Since a couple of
fully-featured apps are better than lots of unfinished ones, why not
join a pre-existing project if you want to make a contribution?

</soapbox>

There would be too much throwing out of code if i was to do the schematic
editor in geda. It is *far* too modal. A keystroke to set a mode is needed
before any little action, and the graphics was hopelessly slow last time
i tried it (DRI on my new video card might help). It doesn't work well when
a newbie comes along to a communal project and obsoletes half the code that
was recently written.
The library management in *every* commercial
and free schematic editor i've seen is just complete crap. *Decent* hierarchial
libraries and schematics are only available in software for many $$$, and even
then, there's a ton of beauracratic bull in generating new library components in
many cases.
Many projects get abandoned half done because they're hobby efforts
done by someone until they get interested in something else. The things *i* do
are absolutely required for my own use, and could be released if it makes sense.
I have saved a certain amount of time by tracing thru some existing drawing
programs, but that was only to get a general idea of the techniques involved
in drawing programs and how the graphics toolkits were used. The biggest
problems with cad software are that they're written primarily by softwarers.
And anyway, i've asked tough questions on the lists of some projects and
the answers you get are few if any.
The only way to get anywhere is to
master the relevant toolkits (such as GTK2+, QT, etc) by writing something
first, then you can anticipate the workings of other projects and improve
them and trace bugs much easier, getting ideas along the way for your own
code. Three different programs for the same thing is better than one,
because more ideas are put into the separate projects that can be copied
between each other and into other programs in completely different fields.
That availability of ideas to look and copy is why open source is much
better than closed source. No more vendor lock-in of proprietory cad formats.
I find most open-source cad projects are still too immature and i wouldn't
use any at this point.