XSpice codemodeling for dummies?

[Stuart Brorson]

Hello,

I will need to create a model of a semiconductor device based upon its
physics -- that is, based upon the constituitive relations,
depletion lengths, Fermi levels, and all that other junk you find in
Sze. I am probably going to do it using an XSpice codemodel.

I am kind of confused about how I can model the C(V) behavior
of the device, because as far as I know the IOs provided by a
codemodel only allow you to input/output voltages and/or currents, and
I don't know how to put in time information (i.e. to support the
differentiating behavior of the cap).

Is anybody here aware of a good text-book which would illuminate
the internal workings of SPICE, and provide a guide to extending it
using XSpice codemodels? I have looked at a few on-line theses and
such, but I need something more like "codemodels for dummies".

Any suggestions?

Stuart

 

[Kevin Aylward]

Stuart Brorson wrote:

Hello,

I will need to create a model of a semiconductor device based upon its
physics -- that is, based upon the constituitive relations,
depletion lengths, Fermi levels, and all that other junk you find in
Sze. I am probably going to do it using an XSpice codemodel.

I am kind of confused about how I can model the C(V) behavior
of the device, because as far as I know the IOs provided by a
codemodel only allow you to input/output voltages and/or currents, and

No, there is a general integrator method.

I don't know how to put in time information (i.e. to support the
differentiating behavior of the cap).

Copy and extend the code in cml\capacito\cfunc.c

i.e. use

cm_analog_integrate(private->conn[0]->port[0]->input.rvalue /
private->param[0]->element[0].rvalue, vc, &partial);

Formulate all equations in terms of integrations.

Is anybody here aware of a good text-book which would illuminate
the internal workings of SPICE, and provide a guide to extending it
using XSpice codemodels? I have looked at a few on-line theses and

I assume you have the xspice manual,
http://www.anasoft.co.uk/xspice_pdf.zip

such, but I need something more like "codemodels for dummies".

No chance. XSpice code modelling is very specialised. Sure, most of the
main vendors use XSpice as a base, but there are only about 20 of them,
so how many engineers do you think that are actually familiar with
detailed XSpice code, considering there are millions of generic MS
visual++ programmers?

Realistically, your going to have to plough through the code yourself to
figure out how it works.

Any suggestions?

Try a different problem

Or, copy an existing set of files from the Spice3 part, and modify the
equations.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Stuart,

I will need to create a model of a semiconductor device based upon its
physics -- that is, based upon the constituitive relations,
depletion lengths, Fermi levels, and all that other junk you find in
Sze. I am probably going to do it using an XSpice codemodel.

I am kind of confused about how I can model the C(V) behavior
of the device, because as far as I know the IOs provided by a
codemodel only allow you to input/output voltages and/or currents,
and I don't know how to put in time information (i.e. to support
the differentiating behavior of the cap).

It's probably much easier to just write this type of spice device
without using xspice. That's been my experience anyway. Integration
of the general non-linear capacitance isn't too hard to figure
out. LTspice has an arbitrary capacitance device that is useful for
rapid prototyping new charge models. I'm not much of a fan of xspice
and I have not seen it used by the major SPICE programs like LTspice,
PSpice, hspice, or Spectre.

Is anybody here aware of a good text-book which would illuminate
the internal workings of SPICE, and provide a guide to extending it
using XSpice codemodels? I have looked at a few on-line theses and
such, but I need something more like "codemodels for dummies".

There's various books on how SPICE works, the 2nd edition of the one
JT suggests is one I always recommend and you will need, but doesn't
address SPICE internals. A good one there is the one by Pillage and
Rohrer. I've been thinking of writing one myself, but until then
you should just get every one you can find if you want to get involved
in this. It's a interesting endeavor. You'll find yourself in club
smaller than the number of people that walked on the moon.

--Mike

 

[Kevin Aylward]

Mike Engelhardt wrote:

Stuart,

I will need to create a model of a semiconductor device based upon
its physics -- that is, based upon the constituitive relations,
depletion lengths, Fermi levels, and all that other junk you find in
Sze. I am probably going to do it using an XSpice codemodel.

I am kind of confused about how I can model the C(V) behavior
of the device, because as far as I know the IOs provided by a
codemodel only allow you to input/output voltages and/or currents,
and I don't know how to put in time information (i.e. to support
the differentiating behavior of the cap).

It's probably much easier to just write this type of spice device
without using xspice. That's been my experience anyway.

Obviously, since your experience is not with xspice, it would be much
easier, with your experience, to write new models in the method you
already know.

In principle, once the learning curve has been done, its much more
easier, to add device models in xspice using its code modelling feature,
then it is in Spice3. For starters, instead of the 20+ files of Spice3
for a model type, there are only two c files, and one of these are
generated automatically by a model port specification file and an xspice
specific helper program. The fundamental feature of the xspice code
modelling was that is was designed for easier addition of new models. It
has a very systematic, general way of doing so.

Integration

of the general non-linear capacitance isn't too hard to figure
out. LTspice has an arbitrary capacitance device that is useful for
rapid prototyping new charge models. I'm not much of a fan of xspice
and I have not seen it used by the major SPICE programs like LTspice,
PSpice, hspice, or Spectre.

This depends on how one defines major, and how observant some particular
individuals are. HSpice and Spectra, while much used in the i.c.
industry, has a relatively low numbers of users, in part based on the
$50k type cost of such Unix based products, and the relatively few
numbers of i.c. designers compared to board level designers.
Spice3/XSpice have 100,000's of users, so is indeed a major spice
platform. As as been pointed out, EWB claim the most customers in the
known universe for their XSpice based product.

Is anybody here aware of a good text-book which would illuminate
the internal workings of SPICE, and provide a guide to extending it
using XSpice codemodels? I have looked at a few on-line theses and
such, but I need something more like "codemodels for dummies".

There's various books on how SPICE works, the 2nd edition of the one
JT suggests is one I always recommend and you will need, but doesn't
address SPICE internals. A good one there is the one by Pillage and
Rohrer. I've been thinking of writing one myself,

Good. I look forward to your book. I hope you include your secrets for
simulation speed up so I can use them myself.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Kevin,

It's probably much easier to just write this type of spice
device without using xspice. That's been my experience
anyway.

Obviously, since your experience is not with xspice, it would
be much easier, with your experience, to write new models in
the method you already know.

You are mistaken. I do have xspice experience. I was once
associated with a SPICE vender who's product was xspice based.
My disdain for the code and it's methods is firmly based in
extended experience with it. The mixed-mode simulator and HDL
used in LTspice came after a moment of clarity that dictated
an entirely different approach and subsequently throwing out
all of xspice.

The fundamental feature of the xspice code modelling was that
is was designed for easier addition of new models. It has a
very systematic, general way of doing so.

Yes, that was the goal. It's good you've come to understand
the xspice mission. I've seen people selling xspice simulators
that didn't know that the mixed-mode simulation capability
was a demo of this feature. But at the end of the day, I see
xspice as a failure of that goal. For me, there's too many
things to do in the rest of the simulator when new device types
are added. E.g., LTspice uses a much more flexible organization
that allows circuit and matrix manipulation beyond what
spice3f5/xspice allow.

of the general non-linear capacitance isn't too hard to
figure out. LTspice has an arbitrary capacitance device
that is useful for rapid prototyping new charge models.
I'm not much of a fan of xspice and I have not seen it
used by the major SPICE programs like LTspice, PSpice,
hspice, or Spectre.

This depends on how one defines major, and how observant some
particular individuals are. HSpice and Spectra, while much
used in the i.c. industry, has a relatively low numbers of
users, in part based on the $50k type cost of such Unix based
products, and the relatively few numbers of i.c. designers
compared to board level designers. Spice3/XSpice have
100,000's of users, so is indeed a major spice platform. As
as been pointed out, EWB claim the most customers in the
known universe for their XSpice based product.

Major demands some respectability. LTspice, PSpice, hspice,
and Spectre command that in my view whereas EWB does not
command the same level of respectability. It's IC designers
that really test the SPICE's. I don't think too much of a
SPICE that can't do reliable transistor-level full-chip
simulation. The academics codes can't do that out without
extensive re-thinking and work. If user-base by and of itself
means anything, LTspice is downloaded every 5min., 24hrs a day,
365.25 days a year, for the last few years, not even including
updates(The Tools=>Sync release command) and downloads from
cached sites at universities for course work. That also
doesn't count that LTspice is also widely redistributed on
third-party CD's, like one last year that went out with a
German electronics magazine and other collections of freeware
EDA software. I think any estimate one could make on the
number of distributed copies would beat a minor(in my opinion)
SPICE like EWB.

--Mike

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

It's probably much easier to just write this type of spice
device without using xspice. That's been my experience
anyway.

Obviously, since your experience is not with xspice, it would
be much easier, with your experience, to write new models in
the method you already know.

You are mistaken. I do have xspice experience.

I don't deny this. I meant to point out that you have spent considerably
more time writing and developing code for non xspice based simulators.
As you note below, you throw the xspice code away. This means it is de
facto more easier for you to make additions to non xspice based code.

I was once
associated with a SPICE vender who's product was xspice based.
My disdain for the code and it's methods is firmly based in
extended experience with it. The mixed-mode simulator and HDL
used in LTspice came after a moment of clarity that dictated
an entirely different approach and subsequently throwing out
all of xspice.

The fundamental feature of the xspice code modelling was that
is was designed for easier addition of new models. It has a
very systematic, general way of doing so.

Yes, that was the goal. It's good you've come to understand
the xspice mission. I've seen people selling xspice simulators
that didn't know that the mixed-mode simulation capability
was a demo of this feature. But at the end of the day, I see
xspice as a failure of that goal.

It certainly missed doing a check on fopen() when reading a state
description file. It proceeded merrily alone blissfully unaware it was
using a null file handle. The state machine code I got didn't actually
work at all until I fixed it, maybe It didn't allocate memory for
some of its arrays.

For me, there's too many
things to do in the rest of the simulator when new device types
are added.

Although, in practice, its not that often that one really needs to add a
new device. New features can be quite nice though. Have you figured out
how my DeviceDesigner feature works yet? Not that I will admit to any
method in public, even if guessed at correctly.

Actually, the xspice capacito code, as is, doesn't work either. It puts
a s/c on its terminals for dc operating point and initial transients. I
was going to add in esr to it, couldn't be bothered after I realised
that I would have to fix this issue as well. I'm just going to add new
features, the basic engine has more than enough for 99% of users.

Oh. yeah, I had to add in an end resistance parameter to the xspice pot.
Setting the rotation to 0 or 1 on a schematic, yep you guessed it,
divide by zero

E.g., LTspice uses a much more flexible organization

that allows circuit and matrix manipulation beyond what
spice3f5/xspice allow.

of the general non-linear capacitance isn't too hard to
figure out. LTspice has an arbitrary capacitance device
that is useful for rapid prototyping new charge models.
I'm not much of a fan of xspice and I have not seen it
used by the major SPICE programs like LTspice, PSpice,
hspice, or Spectre.

This depends on how one defines major, and how observant some
particular individuals are. HSpice and Spectra, while much
used in the i.c. industry, has a relatively low numbers of
users, in part based on the $50k type cost of such Unix based
products, and the relatively few numbers of i.c. designers
compared to board level designers. Spice3/XSpice have
100,000's of users, so is indeed a major spice platform. As
as been pointed out, EWB claim the most customers in the
known universe for their XSpice based product.

Major demands some respectability.

I dont really agree with this. There is only one real applicable
definition of major in the commercial world. This is net sales/profit.
Porn videos can hardly be called respectable in a pure sense, but its a
$billion market, with is indeed a respectable figure.

LTspice, PSpice, hspice,
and Spectre command that in my view whereas EWB does not
command the same level of respectability.

What about Simetrix, or Intusoft's IsSpice which are both based on
XSpice. Both claim major improvements to the speed and convergence. I
believe they both claim full ability to run the standard benchmark
circuits.

It's IC designers
that really test the SPICE's.

Indeed. However, this still does not negate that fact that i.c designers
make up, probably, < 1% of all spice users.

I don't think too much of a
SPICE that can't do reliable transistor-level full-chip
simulation.

Most board level designers, in general, don't need the ability to
simulate 10,000 transistor analogue circuits, so its a particular view
that is not important these particular engineers.

This is really one of an engineering idealist/perfectionist, verses the
practicalities of what is really required by the majority of the market
place.

The academics codes can't do that out without

extensive re-thinking and work. If user-base by and of itself
means anything, LTspice is downloaded every 5min., 24hrs a day,
365.25 days a year, for the last few years, not even including
updates(The Tools=>Sync release command) and downloads from
cached sites at universities for course work. That also
doesn't count that LTspice is also widely redistributed on
third-party CD's, like one last year that went out with a
German electronics magazine and other collections of freeware
EDA software. I think any estimate one could make on the
number of distributed copies would beat a minor(in my opinion)
SPICE like EWB.

This is indeed a well reasoned argument, but it somewhat missies the
point of the original post I think. Indeed, once the source code for
LTSpice, PSpice, HSpice or Spectre is released to the public so that
individuals who want to add their own models to a Spice are abe to, this
argument might well have same merit. However, in the absence of such
facilities, there is only one, rational, practical choice available,
that is to use either the Spice3 or XSpice code, which is, of course,
freely available. The XSpice being the better choice because it includes
all of the Spice3 code, fixes the removal of poly(), plus has some more
useful features to boot.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Kevin,

It's probably much easier to just write this type of spice
device without using xspice. That's been my experience
anyway.

Obviously, since your experience is not with xspice, it would
be much easier, with your experience, to write new models in
the method you already know.

You are mistaken. I do have xspice experience.

I don't deny this. I meant to point out that you have spent
considerably more time writing and developing code for non
xspice based simulators.

The point is make you claims in complete ignorance and
make false asserts of other's knowledge. My opinion that
it's easier to add a new semiconductor device to spice3
than xspice is based on extensive experience with each.

E.g., LTspice uses a much more flexible organization
that allows circuit and matrix manipulation beyond what
spice3f5/xspice allow.

of the general non-linear capacitance isn't too hard to
figure out. LTspice has an arbitrary capacitance device
that is useful for rapid prototyping new charge models.
I'm not much of a fan of xspice and I have not seen it
used by the major SPICE programs like LTspice, PSpice,
hspice, or Spectre.

This depends on how one defines major, and how observant some
particular individuals are. HSpice and Spectra, while much
used in the i.c. industry, has a relatively low numbers of
users, in part based on the $50k type cost of such Unix based
products, and the relatively few numbers of i.c. designers
compared to board level designers. Spice3/XSpice have
100,000's of users, so is indeed a major spice platform. As
as been pointed out, EWB claim the most customers in the
known universe for their XSpice based product.

Major demands some respectability.

I dont really agree with this.

That shows.

There is only one real applicable definition of major
in the commercial world. This is net sales/profit.
Porn videos can hardly be called respectable in a pure
sense, but its a $billion market, with is indeed a
respectable figure.

But LTspice top's the list of SPICE's by your commercial
definition. SPICE is small industry, so many millions
per year -- not billions. LTspice has helped sell
billions of SMPS products and has be called the most
successful piece of sales collateral in engineering
history. Does LTspice's superlative commercial success
mean only what I say is correct and whatever anybody else
says is incorrect? Citing commercial success is not a
convincing point in technical matters.

What about Simetrix, or Intusoft's IsSpice which are
both based on XSpice. Both claim major improvements
to the speed and convergence. I believe they both
claim full ability to run the standard benchmark
circuits.

I've not evaluated Simetrix, but years ago I did evaluate
IsSpice. Benchmarks quickly indicated those claims were
baseless. I still have images of Intusoft's V.P. frothing
at the mouth at a DAC conference when confronted with
this. He insisted that all SPICE's used the same code
and ran the same, just like you used to and so many other
junk SPICE vendors who command no respect in my opinion.

I don't think too much of a SPICE that can't do reliable
transistor-level full-chip simulation.

Most board level designers, in general, don't need the ability
to simulate 10,000 transistor analogue circuits, so its a
particular view that is not important these particular engineers.

This is really one of an engineering idealist/perfectionist,
verses the practicalities of what is really required by the
majority of the market place.

Of course not. SPICE's that can't do difficult IC simulation
give move problems doing board-level simulations. There exist
independently collected IC benchmarks in academia. There isn't
this established culture for the for board level simulation.
Of course, just because a SPICE does the best at IC simulation
doesn't mean it will necessary be the best for board level.
You'll note that many people in this usegroup like LTspice for
board level simulations because it can run PSpice macromodels
and semiconductors, something that xspice can't. The standard
for macromodels PSpice syntax, an enhanced language of
spice3 and not part of xspice.

The academics code can't do that out without
extensive re-thinking and work. If user-base by and of itself
means anything, LTspice is downloaded every 5min., 24hrs a day,
365.25 days a year, for the last few years, not even including
updates(The Tools=>Sync release command) and downloads from
cached sites at universities for course work. That also
doesn't count that LTspice is also widely redistributed on
third-party CD's, like one last year that went out with a
German electronics magazine and other collections of freeware
EDA software. I think any estimate one could make on the
number of distributed copies would beat a minor(in my opinion)
SPICE like EWB.

This is indeed a well reasoned argument, but it somewhat missies
the point of the original post I think. Indeed, once the source
code for LTSpice, PSpice, HSpice or Spectre is released to the
public so that individuals who want to add their own models to
a Spice are abe to, this argument might well have same merit.
However, in the absence of such facilities, there is only one,
rational, practical choice available, that is to use either the
Spice3 or XSpice code, which is, of course, freely available.
The XSpice being the better choice because it includes all of
the Spice3 code, fixes the removal of poly(), plus has some
more useful features to boot.

Between spice3f5 and xspice, xspice is bigger and harder to
understand. If want to actually succeed in adding a new a
semiconductor device, my experience is it's easier to add it to 3f5
than to xspice. There are so many related examples to choose
from as a starting point. If you want to add some special
function logic device, it would be easier *in principle* to
add to xspice. But if you actually learn/know SPICE internals,
then my direct experience again is that it's easier to add to
spice3f5. After-all, you may quickly realize that your new
special function requires a change in the overall SPICE
integration algorithm. Anyway, I have actually been in that
situation and choose that path. Now, years later, hindsight
reinforces the soundness of that decision. I think you will
find it easier to add new devices yourself to spice3 than to
go through xspice's confining organization if you actually
go through and succeed at the exercise.

--Mike

 

[Mike Engelhardt]

...The fundamental reason, as I noted, there are 20+ c files to
mess with compared to 2 if you generating a completely *new*
model. Its a simple numbers game. There is far more to go
wrong with 10 times the number of files...

Kevin, you are a waste of time. This is one of the
stupidest software engineering arguments I've ever seen.
Each file only contains one function, most of which aren't
needed. You can add all the functions in one file or even
tack them in to some existing file so you can add a new
device without added any files. Semiconductive models are
typically added directly in a SPICE3 framework, e.g. BSIM3,
SOI, EKV or VDMOS, not inside the xspice code model framework.

SPICE uses a interesting combination of many different
technologies including device physics, fantastically
specialized numerical methods, various compiler
technologies and general computer science as well
as garden variety software engineering. It's no
place for anyone who doesn't want to be interdisciplinarian.
If a restrictive environment like xspice helps a pedestrian
enter, that would be good. Maybe the original poster
will be the first person to introduce a widely
accepted new semiconductor model with xspice code models.

But, I don't care how people add models to SPICE or who
takes my advice or not. There's nothing in it for me.

--Mike

 

[Steve Hamm]

On Thu, 11 Sep 2003 23:09:57 -0000, Stuart Brorson <sdb@cloud9.net>
wrote:

I will need to create a model of a semiconductor device based upon its
physics -- that is, based upon the constituitive relations,
depletion lengths, Fermi levels, and all that other junk you find in
Sze. I am probably going to do it using an XSpice codemodel.

I am kind of confused about how I can model the C(V) behavior
of the device, because as far as I know the IOs provided by a
codemodel only allow you to input/output voltages and/or currents, and
I don't know how to put in time information (i.e. to support the
differentiating behavior of the cap).

By far the easiest way of doing this is to use a simulator that
implements Verilog-A. Verilog-A allows expressing general
differential-algebraic equations, so c(v) behavior (more properly,
q(v) behavior) would be just i(br) <+ ddt(q);

There's a bit of a movement toward coding _all_ spice models in
Verilog-A, then letting a compiler handle generation of the code to
interface to the simulator... Not a bad idea, really. There's enough
to worry about in getting the physics right, without having to wonder
about introducing bugs in plugging things into the simulator.

Is anybody here aware of a good text-book which would illuminate
the internal workings of SPICE, and provide a guide to extending it
using XSpice codemodels? I have looked at a few on-line theses and
such, but I need something more like "codemodels for dummies".

Internal workings of spice: Nagel's dissertation and Quarles' notes on
spice3. In looking at xspice, the code models seem a bit of a kluge;
I've always wondered if they work well enough to model anything very
complex.

--Steve

 

[Kevin Aylward]

Mike Engelhardt wrote:

...The fundamental reason, as I noted, there are 20+ c files to
mess with compared to 2 if you generating a completely *new*
model. Its a simple numbers game. There is far more to go
wrong with 10 times the number of files...

Kevin, you are a waste of time. This is one of the
stupidest software engineering arguments I've ever seen.

You mean you don't understand the point made.

Each file only contains one function, most of which aren't
needed. You can add all the functions in one file or even
tack them in to some existing file so you can add a new
device without added any files.

You missed the point completely. Sure, some of the files are not that
involved, however, its the number of concepts in the files that matter.
There's load this, add that, parse the other etc...XSpice code models
are much cleaner.

Semiconductive models are

typically added directly in a SPICE3 framework, e.g. BSIM3,
SOI, EKV or VDMOS, not inside the xspice code model framework.

I know. I have done this myself. However, this does appear to highlight
a decrepancy of one of your prior claims. Yo have stated in the past,
that LTSpice is essentially a complete rewrite of the Spice code,
containing maybe 5% of it. This seems a little odd as I assume you
simple added in these external suites of, SOI, parker jfet files etc as
is. How is it that a rewrite has the same basic architecture, even down
to the same "doAnalysis" error messages?

SPICE uses a interesting combination of many different
technologies including device physics, fantastically
specialized numerical methods, various compiler
technologies and general computer science as well
as garden variety software engineering. It's no
place for anyone who doesn't want to be interdisciplinarian.

Yeah, right on. Next you'll be saying that only those potential
Mozart's, and Brahms should be the ones allowed to take a music class.

Your holy than thou pretentiousness crap, shown here, is again typical
of your approach. What we have here is an individual who simple wants to
do some work with a new model. He isn't trying to reinvent the theory of
relativity. Spice isn't a closed club for the specially anointed. The
reality is that most engineering is not done by "multidisciplinary"
experts, nor is there any requirement that this be the case, or should
be th case.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Chuck Harris]

Yeah, right on. Next you'll be saying that only those potential
Mozart's, and Brahms should be the ones allowed to take a music class.

Not take a music class; but rather, would you like the results of a once
in a blue moon musician tampering with a few measures of Beethoven's
5th? Sure, he doesn't understand the whole work, but surely he can
"improve" it by adding/changing a note or two here or there...

Your holy than thou pretentiousness crap, shown here, is again typical
of your approach. What we have here is an individual who simple wants to
do some work with a new model. He isn't trying to reinvent the theory of
relativity. Spice isn't a closed club for the specially anointed. The
reality is that most engineering is not done by "multidisciplinary"
experts, nor is there any requirement that this be the case, or should
be th case.

Actually it is pretty much a closed club. The number if folks that can
successfully create a useful model for ANY spice is very few. You can't
do it unless you understand both spice, and the underlying physics of
the device very well. You can tweek some "Beethoven's" model here and
there and *perhaps* get a useful result, but to successfully make a new
model out of "whole cloth" isn't likely. Your success has little to
do with the internal mechanics of the spice you are modeling for; but
alot to do with your interdisciplinary knowledge (of spice, software
engineering, electronics, physics, etc.).

That's why spice modelers get paid the big bucks by semiconductor
manufacturers.


-Chuck Harris

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

You're
free to have you're own opinion on the way to add devices
to SPICE. There's no need to attack me.

I was not attacking you. It was you who made the personal comment
"Kevin, you are a waste of time."

SPICE uses a interesting combination of many different
technologies including device physics, fantastically
specialized numerical methods, various compiler
technologies and general computer science as well
as garden variety software engineering. It's no
place for anyone who doesn't want to be interdisciplinarian.

Yeah, right on. Next you'll be saying that only those potential
Mozart's, and Brahms should be the ones allowed to take a music
class.

Never said any such thing.

What part of "next you'll be saying..." do you have trouble with?

All application software is
interdisciplinarian, otherwise it has no application --
except possibly compiler writing. My advice was spirited
as an invitation to take it up.

Any subject can be taken as "interdisciplinarian". Electronics design
nessesarily requires English (or another language) to write a spec. I
took the implication that you were inferring that one *requires*
expertise in many subjects.

My guess is that your only problem is that you don't like
that fact I think xspice is not worthwhile

Nonsense. Your opinion matters zilch. Again you have this habit of
denying the actual facts of the case. XSpice is SPice3 with eXtensions.
Spice3/XSpice is a well used and trusted spice platform used by hundreds
of thousands of people.

Once you actually get someone to pay for your product, you opinion on
what constitutes a worthwhile product means nothing. I'm glad you have
delusional comfort in how great your product is, despite the fact that,
essentially, no one would use if it were not free.

and that bothers
you because you like to spam the newsgroups

I don't recall anyone complaining that I Spam the NG.

with a product
proudly based on it.

Indeed. I get many positive reports on my product.

It's not possible to discuss the
matter reasonably with an idiot who proudly flaunts the

The you go again. One of your usual scientific, objective comments.

scruples of a porn star.

Oh...so you must be one of those religious zealots who think sex is sex
is disgusting, dirty, cheap, shouldn't be allowed except in the bedroom
sort of fellow, despite the fact that all 6.3 Bilion of us are here
because of it.

It doesn't matter what other
people say,

Not at all. It doesn't matter what you say.

you just want to plug your product as much
as possible.

Indeed, as do all competent businessmen.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Stuart Brorson]

Chuck Harris <cfharris@erols.com> wrote:
: > Yeah, right on. Next you'll be saying that only those potential
:> Mozart's, and Brahms should be the ones allowed to take a music class.

: Not take a music class; but rather, would you like the results of a once
: in a blue moon musician tampering with a few measures of Beethoven's
: 5th? Sure, he doesn't understand the whole work, but surely he can
: "improve" it by adding/changing a note or two here or there...

:>
:> Your holy than thou pretentiousness crap, shown here, is again typical
:> of your approach. What we have here is an individual who simple wants to
:> do some work with a new model. He isn't trying to reinvent the theory of
:> relativity. Spice isn't a closed club for the specially anointed. The
:> reality is that most engineering is not done by "multidisciplinary"
:> experts, nor is there any requirement that this be the case, or should
:> be th case.

: Actually it is pretty much a closed club. The number if folks that can
: successfully create a useful model for ANY spice is very few. You can't
: do it unless you understand both spice, and the underlying physics of
: the device very well. You can tweek some "Beethoven's" model here and
: there and *perhaps* get a useful result, but to successfully make a new
: model out of "whole cloth" isn't likely. Your success has little to
: do with the internal mechanics of the spice you are modeling for; but
: alot to do with your interdisciplinary knowledge (of spice, software
: engineering, electronics, physics, etc.).

I don't understand the point of your post, unless you just want to
play the part of an overweening, elitist twit. I say: If you have to
be Beethoven just in order to play the fiddle, then there will be no
music anywhere.

More to the point: if SPICE hacking were a closed club, only to be
attempted by carefully groomed initiates, then analog simulation
could not evolve and improve. Fortunately, you don't have to wear a
secret SPICE decoder ring in order to understand enough physics &
electronics to make improvements to SPICE. There are plenty of
educated people out there who have the skills and interest to
contribute. The multitude of different SPICE packages, commercial and
freeware, demonstrates that. Yes, they may all come from the same
root, but they are all now different, with different facilities built
into them by different people to suit different purposes. That's
progress.

Moreover, XSpice was created with an explicit mechanism for extension,
which allows people to create their own models. My initial post was
a reasonable request to see if anybody had recommendations for books
documenting that faculty (besides the XSpice manual). Nobody needs to
wear a SPICE priesthood robe in order to extend the program using
those hooks.

: That's why spice modelers get paid the big bucks by semiconductor
: manufacturers.

I suspect that that's a thing of the past, and that many SPICE
modelers are paid $30K/yr and live in India these days. The skills
and knowledge are available to any intelligent person who takes the
time to learn them, regardless of where they live, or whether they
carry an "exclusive SPICE hacker's club" membership card.

Stuart

 

[Jim Thompson]

On Mon, 15 Sep 2003 07:45:32 +0100, "Kevin Aylward"
<kevin@anasoft.co.uk> wrote:

Mike Engelhardt wrote:

Children! Could you take this private? Thanks!

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Chuck Harris]

Stuart Brorson wrote:

Chuck Harris <cfharris@erols.com> wrote:

I don't understand the point of your post, unless you just want to
play the part of an overweening, elitist twit. I say: If you have to
be Beethoven just in order to play the fiddle, then there will be no
music anywhere.

That you don't understand is quite clear from your post. My point is
that if you don't take the time to learn a multidisciplinary collection
of electrical engineering, physics, and software engineering skills,
your efforts at modeling parts will be unlikely to result in anything
useful.

There is little that is less useful than a spice model that doesn't
accurately represent the physical charecteristics of the part being
modeled.

More to the point: if SPICE hacking were a closed club, only to be
attempted by carefully groomed initiates, then analog simulation
could not evolve and improve. Fortunately, you don't have to wear a
secret SPICE decoder ring in order to understand enough physics &
electronics to make improvements to SPICE. There are plenty of
educated people out there who have the skills and interest to
contribute. The multitude of different SPICE packages, commercial and
freeware, demonstrates that. Yes, they may all come from the same
root, but they are all now different, with different facilities built
into them by different people to suit different purposes. That's
progress.

The "club" isn't closed by any authority. It is one of those "clubs"
where if you don't already know that you are capable of doing the job,
you probably aren't. Life is full of "clubs" like that.

: That's why spice modelers get paid the big bucks by semiconductor
: manufacturers.

I suspect that that's a thing of the past, and that many SPICE
modelers are paid $30K/yr and live in India these days. The skills
and knowledge are available to any intelligent person who takes the
time to learn them, regardless of where they live, or whether they
carry an "exclusive SPICE hacker's club" membership card.

To get into the "club" in India, you not only have to be very well
educated, you also have to be in the correct socio-economic class.

Their pay may suck, but India's programmers and engineers are equal
to any found anywhere in the world. If you had worked with any of
them, you would already know this.

-Chuck

 

[Stuart Brorson]

Chuck Harris <cfharris@erols.com> wrote:
: Stuart Brorson wrote:
:> Chuck Harris <cfharris@erols.com> wrote:
[ . . . . . bla bla bla . . . . .]

: Their pay may suck, but India's programmers and engineers are equal
: to any found anywhere in the world. If you had worked with any of
: them, you would already know this.

Well, I believe that this was my point -- that there are lots of
intelligent, dilligent engineers all over the world who have the
skills, interest, and knowledge to understand and contribute to SPICE
& related programs. And I have indeed worked with plenty of them,
doing both hardware & software, thank you very much.

Your point seemes to be that you have to have a triple PhD in physics,
circuits, and compilers, and belong to the elite SPICE club to get
paid big bux for working on SPICE. This is elitest nonsense.
Moreover, your arguments belie an attitude of sour clubbiness which
don't contribute to your point.

Thanks to everybody for their opinions about XSpice's merits and
demerits. I'll bow out of this thread now.

Stuart

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

...The fundamental reason, as I noted, there are 20+ c files to
mess with compared to 2 if you generating a completely *new*
model. Its a simple numbers game. There is far more to go
wrong with 10 times the number of files...

Kevin, you are a waste of time. This is one of the
stupidest software engineering arguments I've ever seen.
Each file only contains one function, most of which aren't
needed. You can add all the functions in one file or even
tack them in to some existing file so you can add a new
device without added any files. Semiconductive models are
typically added directly in a SPICE3 framework, e.g. BSIM3,
SOI, EKV or VDMOS, not inside the xspice code model framework

You mean you don't understand the point made.

No, you just miss-represent what it takes to add a device
to spice3. I've written about 50 new SPICE devices and
added about 30 new compilers to SPICE. I've worked both
in spice3 and xspice. I certainly have absolutely no
reason not to use xspice if I though it was worthwhile.
I even have a license from Georgia Tech for it. I'm
offering some advice I've found tried and true. You're
free to have you're own opinion on the way to add devices
to SPICE. There's no need to attack me.

I was not attacking you.

It doesn't come across that way.

Only to you. You need to remove that bolder from your shoulder.

In any case I don't
understand why you want to vigorously defend a position

Vigorously is hardly the way it was presented it. On the contrary, its
you who are making the claim that any other method other than the Spice3
route is crap.

that the way to add a new semiconductor model to spice
is in xspice code modeling.

Err.. I suggested both methods were viable. I was the first to suggest
that the poster copy and modify existing spice3 code. They both have
their ups and down.

That's not the way people
usually do that.

Thats history for you. It sets precedents.

And your argument about the 20 files
is completely false.

Nope. The xspice connection port and parameters simplify a few of the
concepts involved. Its a generalised method.

It only takes about three functions,

which to can put in any file you wish,

You dont say?

and there's lot of
semiconductor models to start with to skeletonize.

SPICE uses a interesting combination of many different
technologies including device physics, fantastically
specialized numerical methods, various compiler
technologies and general computer science as well
as garden variety software engineering. It's no
place for anyone who doesn't want to be interdisciplinarian.

Yeah, right on. Next you'll be saying that only those
potential Mozart's, and Brahms should be the ones allowed
to take a music class.

What part of "next you'll be saying..." do you have
trouble with?

Eh? Why tell people what they're going to say?

Er... Its done all the time. Its called a rhetorical question. Look it
up in an English book. Its actually quite common for those not locked up
in their bedrooms typing on computers 23 hours a day.

The
point remains that all application software is
interdisciplinarian. Effective SPICE development uses
a rich combination of electrical engineering,

Rich? Delusions of granduer again. Leave it out mate. You don't half try
and dress up Kirchoff's current and voltage laws.

I've said this before, you should really reread you diatribe from the
point of view of an uninterested party. oh, what was it now, LTSpice is
of "historical proportions", or some similar such waffle.

?device
physics,

The *main* device equation is er.., in one file. What about all the
other 100k+ lines of code that depends not one iota on the physics.
There's vasts amounts of "effective" spice development that can be done
without worrying about any physics at all.

and complier implementation familiarity.

Compiler implementation familiarity? You don't say? Yeah. What sort of
drugs are you on. Its add file, in MS VC++ and your done. I couldn't
implement a compiler even if it resulted in 100 pints of Guinness, per
week.

Next you'll be saying the ability to type with 10 fingers is mandatory,
which would put me in a bit of a predicament as I've only got 8, plus
two thumbs.

My guess is that your only problem is that you don't
like that fact I think xspice is not worthwhile

Nonsense. Your opinion matters zilch. Again you have this
habit of denying the actual facts of the case.

You're the one saying it takes 20+ files to add a new
device to SPICE. This is emphatically false.

I am sure anyone knows that one can put 100k lines of code in one file
if one so chooses. The point here is that if one is going to to add
stuff either XSpice or Spice3 based, the sensible thing to do is use
exactly the same format as the existing stuff. It makes it much easier
to debug by comparison with what is known to work.

XSpice is SPice3 with eXtensions. Spice3/XSpice is
a well used and trusted spice platform used by hundreds
of thousands of people.

But I didn't find the xspice entenstions a good starting
point for adding new semiconductor models. There's no
hundreds of thousands of people trusting xspice for this.
It just that a dozen or so me-too SPICE products use it
as a starting point and they find it threatenting when
they encounter somewone who actually knows how to
write a SPICE program instead.

There you go again. Your the only one in the known universe that
knows/can how to write a spice program. Still full of it I see.

It's not possible to discuss the matter reasonably
with an idiot who proudly flaunts the scruples of a
porn star.

Read over your porn star arguement and thing about it.
It's an unhappy person who is primarily motivated by
money. Even in business.

Not at all. Love can't buy you money.

Once you actually get someone to pay for your product,
you opinion on what constitutes a worthwhile product
means nothing. I'm glad you have delusional comfort in
how great your product is, despite the fact that,
essentially, no one would use if it were not free.

I know this to be false.

Nope you don't. You have zero experimental evidence for that
supposition. As they say, the only valid marketing survey is a signed
purchase order.

Certainly most of the time
I spend on it is with people who are in a position where
the cost of the simulator is irrelevant

Yes, I know the types you deal with. Unfortunately, they aren't the
100,000's who use free spices and that are perfectly willing to spend
$5,000 for PSpice if they thought it was better.

and I recommend
to people that the cost of a SPICE program should not
be a consideration.

Oh dear... Oh dear... oh dear...You don't live in this real world do
you.

Many people do report that they
would pay for it.

People can say what they like, but the proof is in the pudding.

But, in this newsgroup/clientele,
the free aspect of LTspice is a plus to it's popularity.

You believe this drivial don't you. Sad really, but if that whats makes
you happy...

As far as the OT aspect of this thread, my view is that
a business model based on selling SPICE licenses has
gone as far as it can. The SPICE industry is a small
part of EDA these days, just so many million per year.

That many?

If one can take credit

Yes, you do like to do this don't you.

.. for a few parts per thousand of

helping people to apply billions of dollars worth of;
e.g., SMPS's products; then you instantly are in a
position with the resources to swamp the entire SPICE
industry.

I agree, what with not looking a gift horse in the mouth, and giving
away a usable Spice by a billion dollar company, could, in principle,
wipe out the purchased Spice market.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

Jim Thompson wrote:

On Mon, 15 Sep 2003 17:27:13 +0100, "Kevin Aylward"
kevin@anasoft.co.uk> wrote:

Mike Engelhardt wrote:
Kevin,

[snip]

ctrl-K Subject

coming soon if the childishness moves to a new topic: ctrl-K authors

*Anything* at all can be interpreted as "childishness" or "pointless" if
phrased in such manner, so this means nothing.

"why should some spend all day putting a little ball on a little twiggy
thing and whack it about with sticks". "Why should some spend all day
running about with big thingies on third shoulders, throwing misshapen
balls about". "Why should some sit at a table, moving littlie blank and
white things on little black and white squares etc...etc...

So, there....Stick that in you pipe and smoke
it....nah..nah..nah..nah..nah..nah..

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Chuck Harris]

Stuart Brorson wrote:

Your point seemes to be that you have to have a triple PhD in physics,
circuits, and compilers, and belong to the elite SPICE club to get
paid big bux for working on SPICE. This is elitest nonsense.
Moreover, your arguments belie an attitude of sour clubbiness which
don't contribute to your point.

Then you have missed my point completely!


-Chuck

 

[Active8]

In article <nerbmv4ore19pip4obbghsi9bmqaevh445@4ax.com>, Jim-T@golana-
will-get-you.com says...

On Mon, 15 Sep 2003 17:27:13 +0100, "Kevin Aylward"
kevin@anasoft.co.uk> wrote:

Mike Engelhardt wrote:
Kevin,

[snip]

ctrl-K Subject

coming soon if the childishness moves to a new topic: ctrl-K authors

...Jim Thompson

i sometimes look for Kevin/Mike exchanges in the thread view just to
break the monotony this one wasn't very good. the flame level just
wasn't there. they're slacking.

but that brings up something i've been thinking of lately. considering
that the PSpice documentation raises more questions than it answers...
that the docs are nearly useless...

i was thinking it may have been easier to just use SS and LTSpice for
sims. you know, generate a netlist from SS where at least the capture
part is a no brainer. at least creating parts should be easier than it
is in LTSpice. drop the netlist in LTSpice and probe the output in SS.

can you imagine the shit that could get started between those two when i
start hammering them both with questions? ^2

SS *and* LTSpice in the subject lines...

i've saved as many of helmut's LTSpice answers as i came across, just in
case. he's put out some good help for creating new parts. maybe Linear
should put him on the payroll.

brs,
mike