SuperSpice and new component

On Sun, 20 Mar 2005 23:36:12 -0800, ldg <asfd_at_hotmail.com> wrote:

dg, You harp about things that you know not about. LTSpice can run
ANY netlist... you're just too much the amateur to understand how.


For completeness, I suppose I should include an example of the
resistor error messages when the resistor is specified with w/l and a
model.

LTspice is apparently looking for the original spice syntax for the
various parameters in the model and doesn't utilize much of the
foundry supplied resistor model.

The fact that it works for "semiconductor resistors" is not
documented:


Syntax: Rxxx n1 n2 <value> [tc=tc1, tc2, ...]

The resistor supplies a simple linear resistance between nodes n1 and
n2. A temperature dependence can be defined for each resistor
instance with the parameter tc. The resistance, R, at will be

R = R0 * (1. + dt * tc1 + dt**2 * tc2 + dt**3 * tc3 + ...)

where R0 is the resistance at the nominal temperature and dt is the
difference between the resistor's temperature and the nominal
temperature.


Running this file shows the error messages the simulator kicks out.
It does find the sheet resistance and that provides an accurate
nominal simulation in the rc below:



LTSPICE test

V1 1 0 pulse(0 5 10u 1n 1n 1)
R1 1 2 1e4
C1 2 0 1e-9
XR2 1 3 rny10k
C3 3 0 1e-9

.SUBCKT RNY10K a b
RR10 N_1 b NY W=4.4U L=88U
RR9 N_2 N_1 NY W=4.4U L=88U
RR8 N_3 N_2 NY W=4.4U L=88U
RR7 N_4 N_3 NY W=4.4U L=88U
RR6 N_5 N_4 NY W=4.4U L=88U
RR5 N_6 N_5 NY W=4.4U L=88U
RR4 N_7 N_6 NY W=4.4U L=88U
RR3 N_8 N_7 NY W=4.4U L=88U
RR2 N_9 N_8 NY W=4.4U L=88U
RR1 a N_9 NY W=4.4U L=88U
.ENDS RNY10K
.tran 1u 0.1m

.model ny r rsh = 50
+ dw = 0.08e-6 dlr = -0.8e-6
+ cox = 1.3e-4 capsw = 0.060e-9
+ tc1r = 4.0e-4 tc2r = 1.1e-6
+ tref = 25
*

.end

Again, this works fine in Smartspice. No subcircuits needed :-)

Regards,
Larry

Take it up with Mikey. You've wasted several hours of my time. No
more. Fookin' amateur ;-)

...Jim Thompson
--

dg, You harp about things that you know not about. LTSpice can run
ANY netlist... you're just too much the amateur to understand how.

On Mon, 21 Mar 2005 15:27:08 -0700, Jim Thompson
thegreatone_at_example.com> wrote:

Take it up with Mikey. You've wasted several hours of my time. No
more. Fookin' amateur ;-)

...Jim Thompson
--

To JIM:

Take your lithium. Rent Napoleon Dynamite. Grab a good cabernet and
enjoy life :-)

You may want to reconsider saying things like this to others - "You
harp about things that you know not about". I was curious at that
point what you might actually know. Not curious now. :-)

TO THE GROUP:

Hopefully the exchange might provide some insight to others on the
various topics and wasn't too distracting. If so, let me apologize.

Sorry for taking over the thread.

I had fun though. :-)

Regards,
Larry

Actually, I was wondering how wine itself works as an emulator.

I'm
supposing it adds another layer between the application and the
hardware and would incur some overhead. Is this not the case?

Some companies have good programmers and others don't. In some cases, it
isn't that the software will not work just fine on some other system, it
just that the maker only tests it on one version and makes their install
script test for that specific version.


So you have to solve the problem caused by the various distro vendors
by writing different install scripts?

I believe there actually is an
attempt to solve this problem by normalizing the libraries so 3rd
party software can always find them.

This seems like a better
solution, but so far the various vendors haven't complied. Redhat
probably thinks their user base is "captured" by the way they have
these libraries arranged. The other vendors apparently refuse to
follow Redhat.

One of the issues with switching to linux is that 3rd party software
vendors seem to not want to port their code to it. Nero did recently
and has been taking flack because their code is proprietary. If the
linux community wants linux to grow, they should encourage such
things. It also means they should take steps to ensure easy
operability between distros I think.

So far I've tried Fedora, Xandros, and SuSE. SuSE seemed to set up
the hardware more easily, though Xandros was also very good. Using a
memory stick on Fedora meant creating a special mount directory and
going through that process. SuSE and Xandros seemed to just recognize
a memory stick automatically. Only Xandros automatically set up Samba
so that it would function on my lan with win2k machines.

In article <1jrt31dugusf979slo3ndso49t0opn1kkv_at_4ax.com>,
ldg <asfd_at_hotmail.com> wrote:
[....]
Actually, I was wondering how wine itself works as an emulator.

Wine works very well indeed as an emulator even though it is in fact not
an emulator but a port of the windows API onto linux.

I'm
supposing it adds another layer between the application and the
hardware and would incur some overhead. Is this not the case?

Consider the case of a request to write to a file:

The typical Windows application does this:

(1) The object that is requesting to be written calls its virtual method
that is used for writing.

(2) The write virtual method calls the virtual method for each of its
component parts.

(3) Each component part calls the virtual method that is part of the file
handling stuff in MFC.

(4) The file handling stuff creates the needed structure to pass to the
windows API.

(5) The windows API recieves the request and burries it in warm peat for
aging.

(6) The windows API hands the request to the 32 bit DOS function.

(7) The 32 bit DOS function calls the section of the device driver that
does writing

( The device driver waits for the tubes in the disk drive to warm up and
then dribbles the data into the srive.

Under wine, items 5 to 8 change to this:

(5) The wine code recieves the request.

(6) wine passes the request to the kernal function

(7) The kernal transfers the data to a buffer and flags it as needing to
be written.

( When time permits or there are not enough buffers left, the Kernal
calls the code for writing on this type of disk.

(9) The write actually happens.

Some companies have good programmers and others don't. In some cases, it
isn't that the software will not work just fine on some other system, it
just that the maker only tests it on one version and makes their install
script test for that specific version.


So you have to solve the problem caused by the various distro vendors
by writing different install scripts?

In many cases, it is just a matter of using the software from the good
programmers and ignoring the software from the bad ones.

I believe there actually is an
attempt to solve this problem by normalizing the libraries so 3rd
party software can always find them.

It is less about normalizing and more about picking a minimum standard and
going with that.

RANT
Bad programmers assume that the target machine has all the latest stuff.
Good programmers only enforce the requirements that actually matter in
their code. Bad programmers hard code the locations and versions of
everything. Good programmers allow for things to be specified at install
time.
\RANT

This seems like a better
solution, but so far the various vendors haven't complied. Redhat
probably thinks their user base is "captured" by the way they have
these libraries arranged. The other vendors apparently refuse to
follow Redhat.

Dead Rat has lots of silly ideas. But then so do lots of other folks.
Altera just brought out a version of Quartus that runs under Linux, if you
have the right version of Read Hat and if you have the right version of QT
and if you have the right version of Glibc and if you place your left hand
on top of your head while you install it. All Quartus really is, is a
compiler and a text editor. They could have left the editor out. There
is no reason a compiler needs any such specifics about the machine it will
run on.

[...]

One of the issues with switching to linux is that 3rd party software
vendors seem to not want to port their code to it. Nero did recently
and has been taking flack because their code is proprietary. If the
linux community wants linux to grow, they should encourage such
things. It also means they should take steps to ensure easy
operability between distros I think.

Nero comes free with many DVD burners etc. The free version is not the
Linux version. I think this is why they are getting flack. If they gave
you the Linux version when you bought the DVD burner, most users would not
care that they did not get the source code.

[...]
So far I've tried Fedora, Xandros, and SuSE. SuSE seemed to set up
the hardware more easily, though Xandros was also very good. Using a
memory stick on Fedora meant creating a special mount directory and
going through that process. SuSE and Xandros seemed to just recognize
a memory stick automatically. Only Xandros automatically set up Samba
so that it would function on my lan with win2k machines.


My work machine runs SuSE 9.2. It almost got samba right on the first
try. At home I run SuSE 8.2. The samba set up in it was completely
broken. There are signs of progress.

--
Thanks for the thoughtful reply!