Big bug in PSpice??

Oliver Friedrich · Mar 7, 2007

Hallo,

I've discovered a phenomen which I claim to be a fatal PSpice error, at
least something that I don't understand at all.

Try simulate the following netlist

* source 3_029_B01_TLINEVERIFICATION
V_V_DC N00124 0 2
R_R_DC N00124 C1 52
X_T_DC C1 0 0 0 FIM02YHBY PARAMS: LEN=100
R_R_TRAN N00504 C2 52
V_V_TRAN N00504 0
+PULSE 0 2 10n 1n 1n 1m 2m
X_T_TRAN C2 0 0 0 FIM02YHBY PARAMS: LEN=100

To clarify the whole thing. I have two lines of 100m each. Each line is
shorted at the end and fed via a 2V and 52R resistance. C1 and C2 are the
nodes at the input of the lines.

The subcircuit of the transmission line is
*FIM02YHBY is a shielded twisted pair from Gebauer&Griller
*The shield is not modelled as conductor but its influence on
*the line parameters is accounted.
*Model parameter derived by measurement and calculation. Refer to
*document 3-029-B01-D001 for details.
*6.283 is an approximation of 2*Pi
*Both resistors prevent a node floating error.
*-----------
*Pin Desc
*10 Near end high
*20 Near end low
*30 Far end high
*40 Far end low
..subckt FIM02YHBY NH NL FH FL PARAMS: LEN=1
T NH NL FH FL T1
R1 NH FH {1/GMIN}
R2 NL FL {1/GMIN}
..model T1 TRN(
+r={342m+0*sqrt(s/6.283)}
+l=493.17n
+g={0*(s/6.283)}
+c=45.216p
+ LEN={LEN})
..ends

To my model, skin effect and dielectric losses are prepared but yet not
considered, therefor the 0 in the formulas. All other values I have
measured on a real piece of cable very carefully.

Now make a transient simulation to t=1m. After this time the transient
has settled down to its final state. So the voltage on node C1 and C2
should be the same, cause it is simply a voltage divider from the DC
losses of the line and the source resistors of 52 Ohms.
But my simulation shows a big difference.
C1 is at 793mV which is the correct value assuming that the line has 100m
length and 342mOhm per meter.
C2 is at 1.05V which leads to a DC resistance of 574mOhm per meter.

So what's the story? Why shows the same trasnmission line a DC resistance
of 342mOhm per meter and 574mOhm per meter?

I'm really looking forward to any good explanations, because this
shatters any confidence in the reliability of PSpice.

By the way: I'm running OrCAD Pspice 10.0

Best regards

Oliver Friedrich

Joel Kolstad · Mar 7, 2007

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esmngi$p13$1@news.BelWue.DE...

I've discovered a phenomen which I claim to be a fatal PSpice error, at
least something that I don't understand at all.

I doubt it's really a bug in the PSpice "core" per se, but I wouldn't be
surprised if it's a limitation of the transmission line model PSpice uses, or
perhaps the behavioral modeling code. ("Limitation" implies that the
inaccuracies are known and -- somewhere -- documented, whereas "bug" implies
something's going on that the PSpice designers were unaware of.) You're
asking PSpice to do the following here:

1) Accurately model a lossy transmission line. This is challenging to do
correctly in the general case (you still see the occasional journal papers
where people are trying to create better models).
2) Convert the results back to the time domain for your transient simulation.
This is also difficult (in fact, many SPICE simulators don't even support this
feature).

To someone who's been using SPICE simulators for awhile, the fact that you get
an incorrect answer is not too surprising.

Of course, you *should*
forward your example to ORCAD support and ask them to tell you what's going
on. I'm still placing my bets on the behavior being a known limitation rather
than a bug...

---Joel

Jim Thompson · Mar 7, 2007

On Wed, 7 Mar 2007 08:57:41 -0800, "Joel Kolstad"
<JKolstad71HatesSpam@yahoo.com> wrote:

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esmngi$p13$1@news.BelWue.DE...
I've discovered a phenomen which I claim to be a fatal PSpice error, at
least something that I don't understand at all.

I doubt it's really a bug in the PSpice "core" per se, but I wouldn't be
surprised if it's a limitation of the transmission line model PSpice uses, or
perhaps the behavioral modeling code. ("Limitation" implies that the
inaccuracies are known and -- somewhere -- documented, whereas "bug" implies
something's going on that the PSpice designers were unaware of.) You're
asking PSpice to do the following here:

1) Accurately model a lossy transmission line. This is challenging to do
correctly in the general case (you still see the occasional journal papers
where people are trying to create better models).
2) Convert the results back to the time domain for your transient simulation.
This is also difficult (in fact, many SPICE simulators don't even support this
feature).

To someone who's been using SPICE simulators for awhile, the fact that you get
an incorrect answer is not too surprising. Of course, you *should*
forward your example to ORCAD support and ask them to tell you what's going
on. I'm still placing my bets on the behavior being a known limitation rather
than a bug...

---Joel

I just took a quick glance awhile ago, and didn't have time to
respond, but I'm sure Joel is correct. It appears you are using the
default T-line model for one of your lines... this is idealistic, and
mostly is useful for delay modeling. Use the "lossy" model instead.

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice

480)460-2350 | |
| E-mail Address at Website Fax

Oliver Friedrich · Mar 8, 2007

Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote in
news:18vtu2ludshpjsgbi13nbqgl6cf58ibveh@4ax.com:

On Wed, 7 Mar 2007 08:57:41 -0800, "Joel Kolstad"
JKolstad71HatesSpam@yahoo.com> wrote:

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esmngi$p13$1@news.BelWue.DE...
I've discovered a phenomen which I claim to be a fatal PSpice error,
at least something that I don't understand at all.

I doubt it's really a bug in the PSpice "core" per se, but I wouldn't
be surprised if it's a limitation of the transmission line model
PSpice uses, or perhaps the behavioral modeling code. ("Limitation"
implies that the inaccuracies are known and -- somewhere --
documented, whereas "bug" implies something's going on that the PSpice
designers were unaware of.) You're asking PSpice to do the following
here:

1) Accurately model a lossy transmission line. This is challenging to
do correctly in the general case (you still see the occasional journal
papers where people are trying to create better models).
2) Convert the results back to the time domain for your transient
simulation. This is also difficult (in fact, many SPICE simulators
don't even support this feature).

To someone who's been using SPICE simulators for awhile, the fact that
you get an incorrect answer is not too surprising. Of course, you
*should* forward your example to ORCAD support and ask them to tell
you what's going on. I'm still placing my bets on the behavior being
a known limitation rather than a bug...

---Joel

I just took a quick glance awhile ago, and didn't have time to
respond, but I'm sure Joel is correct. It appears you are using the
default T-line model for one of your lines... this is idealistic, and
mostly is useful for delay modeling. Use the "lossy" model instead.

...Jim Thompson

Hallo Jim,

what do you mean when you are talking of the "lossy model". The T-line
model PSpice provides can be configured with either td and Z0 or it
allows to pass arguments for R L G C. This implies that this model claims
to be capable of modelling a lossy line. I don't know any other
implemented models in PSpice.
Perhaps you mean the lumped elements model with discrete R L G C. But
that's not a model to my understanding but a subcircuit. If you mean
that, I'll give it a try. Are there any other yet to me unknown flaws and
restrictions to expect. Telling me that saves a lot of bother for me;-)

Definetely it is a bad thing if you are spending the major of your time
with trying to bypass restrictions of a tool and discovering the
undocumented "features" in it rather than just to bloody use it.

Every day I work with PSpice gets me a little more unhappy with it. Of
course you are the last one to blame I suppose. This posting is more an
aggregation of all my dissapointments I've experienced with PSpice.

Thank you for your help

Oliver Friedrich

Oliver Friedrich · Mar 8, 2007

"Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote in
news:12utro6pck5pb8c@corp.supernews.com:

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esmngi$p13$1@news.BelWue.DE...
I've discovered a phenomen which I claim to be a fatal PSpice error,
at least something that I don't understand at all.

I doubt it's really a bug in the PSpice "core" per se, but I wouldn't
be surprised if it's a limitation of the transmission line model
PSpice uses, or perhaps the behavioral modeling code. ("Limitation"
implies that the inaccuracies are known and -- somewhere --
documented, whereas "bug" implies something's going on that the PSpice
designers were unaware of.) You're asking PSpice to do the following
here:

1) Accurately model a lossy transmission line. This is challenging to
do correctly in the general case (you still see the occasional journal
papers where people are trying to create better models).
2) Convert the results back to the time domain for your transient
simulation. This is also difficult (in fact, many SPICE simulators
don't even support this feature).

To someone who's been using SPICE simulators for awhile, the fact that
you get an incorrect answer is not too surprising. Of course, you
*should* forward your example to ORCAD support and ask them to tell
you what's going on. I'm still placing my bets on the behavior being
a known limitation rather than a bug...

---Joel

Hallo Joel,

I'm looking forward to get any domentation from you describing this
"restriction".
To me it is an error and nothing else. Don't blandish! The major task of
a simulation model is to simulate its real counterpart as close as
possible. Since you can't model the reality perfectly the most important
information that must be provided with any model is a documentation of
where it is applicable and where it is not applicable. This documentation
must be available and not hidden in a little vague application note on
website xyz of university scoobydoo department PSpice forensics.

These undocumented "features" take away a lot of valuable time from you
and me and everyone. Sure it is inevitable that software has bugs, but
when I discover a bug let me call it a bug.

Sorry if I offended you, it's not your fault, but at the moment I'm angry

Oliver Friedrich

Jim Thompson · Mar 8, 2007

On Thu, 8 Mar 2007 08:26:40 +0000 (UTC), Oliver Friedrich
<oliver.friedrich@tzm.de> wrote:

Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote in
news:18vtu2ludshpjsgbi13nbqgl6cf58ibveh@4ax.com:
[snip]

I just took a quick glance awhile ago, and didn't have time to
respond, but I'm sure Joel is correct. It appears you are using the
default T-line model for one of your lines... this is idealistic, and
mostly is useful for delay modeling. Use the "lossy" model instead.

...Jim Thompson

Hallo Jim,

what do you mean when you are talking of the "lossy model".

Use part name "TLOSSY"

The T-line
model PSpice provides can be configured with either td and Z0 or it
allows to pass arguments for R L G C. This implies that this model claims
to be capable of modelling a lossy line. I don't know any other
implemented models in PSpice.

Part "T" is idealistic

Perhaps you mean the lumped elements model with discrete R L G C. But
that's not a model to my understanding but a subcircuit. If you mean
that, I'll give it a try. Are there any other yet to me unknown flaws and
restrictions to expect. Telling me that saves a lot of bother for me;-)

Definetely it is a bad thing if you are spending the major of your time
with trying to bypass restrictions of a tool and discovering the
undocumented "features" in it rather than just to bloody use it.

Every day I work with PSpice gets me a little more unhappy with it. Of
course you are the last one to blame I suppose. This posting is more an
aggregation of all my dissapointments I've experienced with PSpice.

Thank you for your help

Oliver Friedrich

480)460-2350 | |
| E-mail Address at Website Fax

Jim Thompson · Mar 8, 2007

On Thu, 8 Mar 2007 08:52:01 +0000 (UTC), Oliver Friedrich
<oliver.friedrich@tzm.de> wrote:

"Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote in
news:12utro6pck5pb8c@corp.supernews.com:

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esmngi$p13$1@news.BelWue.DE...
I've discovered a phenomen which I claim to be a fatal PSpice error,
at least something that I don't understand at all.

I doubt it's really a bug in the PSpice "core" per se, but I wouldn't
be surprised if it's a limitation of the transmission line model
PSpice uses, or perhaps the behavioral modeling code. ("Limitation"
implies that the inaccuracies are known and -- somewhere --
documented, whereas "bug" implies something's going on that the PSpice
designers were unaware of.) You're asking PSpice to do the following
here:

1) Accurately model a lossy transmission line. This is challenging to
do correctly in the general case (you still see the occasional journal
papers where people are trying to create better models).
2) Convert the results back to the time domain for your transient
simulation. This is also difficult (in fact, many SPICE simulators
don't even support this feature).

To someone who's been using SPICE simulators for awhile, the fact that
you get an incorrect answer is not too surprising. Of course, you
*should* forward your example to ORCAD support and ask them to tell
you what's going on. I'm still placing my bets on the behavior being
a known limitation rather than a bug...

---Joel

Hallo Joel,

I'm looking forward to get any domentation from you describing this
"restriction".
To me it is an error and nothing else. Don't blandish! The major task of
a simulation model is to simulate its real counterpart as close as
possible. Since you can't model the reality perfectly the most important
information that must be provided with any model is a documentation of
where it is applicable and where it is not applicable. This documentation
must be available and not hidden in a little vague application note on
website xyz of university scoobydoo department PSpice forensics.

These undocumented "features" take away a lot of valuable time from you
and me and everyone. Sure it is inevitable that software has bugs, but
when I discover a bug let me call it a bug.

Sorry if I offended you, it's not your fault, but at the moment I'm angry

Oliver Friedrich

480)460-2350 | |
| E-mail Address at Website Fax

Georg Baum · Mar 8, 2007

Jim Thompson wrote:

On Thu, 8 Mar 2007 08:26:40 +0000 (UTC), Oliver Friedrich
oliver.friedrich@tzm.de> wrote:

Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote in
news:18vtu2ludshpjsgbi13nbqgl6cf58ibveh@4ax.com:
[snip]

I just took a quick glance awhile ago, and didn't have time to
respond, but I'm sure Joel is correct. It appears you are using the
default T-line model for one of your lines... this is idealistic, and
mostly is useful for delay modeling. Use the "lossy" model instead.

...Jim Thompson

Hallo Jim,

what do you mean when you are talking of the "lossy model".

Use part name "TLOSSY"

The T-line
model PSpice provides can be configured with either td and Z0 or it
allows to pass arguments for R L G C. This implies that this model claims
to be capable of modelling a lossy line. I don't know any other
implemented models in PSpice.

Part "T" is idealistic

According to my really old pspice manual (version 6.3) "T" is used for both
the lossy and lossless model. This might have changed in newer versions,
but it was at least valid at some point in time.

Oliver, your pulse source has really strange values. It looks to me as if a
new pulse is started before one minute is over. That could explain the
different voltages.
If your problem still persists please give a complete .cir file, then I
might be able to have a look.

Georg

Joel Kolstad · Mar 8, 2007

Hi Oliver,

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esoirh$ips$1@news.BelWue.DE...

I'm looking forward to get any domentation from you describing this
"restriction".
To me it is an error and nothing else. Don't blandish!

Yeah, but it could be a "user error."

As I say, send your file to ORCAD support, and let a support guy tell you
what's going on.

The major task of
a simulation model is to simulate its real counterpart as close as
possible. Since you can't model the reality perfectly the most important
information that must be provided with any model is a documentation of
where it is applicable and where it is not applicable. This documentation
must be available and not hidden in a little vague application note on
website xyz of university scoobydoo department PSpice forensics.

I agree with this sentiment in general, and I have observed that some software
packages seem to try to hide important information regarding their product's
limitations.

As you ask a simulator to do more complicated things, to get reasonable
results out of it you do get a little "sucked into" having to know how the
simulator works internally. I use field solvers every now and again, and --
compared to SPICE -- it's easy to get absolute nonsense out of them unless
you're very careful. Depending on whose field solver you use, sometimes the
documentation is pretty good about guiding you to run test cases to make sure
the results you're getting are reasonable... other times they just assume
you're well-versed in the subject and don't volunteer a safety harness or life
preserver.

(If you're ever hard up for a paper to get your employer to send you to a
conference, a perennial favorite is to just gather up a half-dozen or so EM
simulators, run some challenging test case such as a spiral inductor on lossy
silicon, and compare and contrast the results.

Some papers like this
don't even have a real, physically-manufactured reference wafer built for
comparison's sake!)

Let us know what Cadence says about your test case... maybe it'll turn out to
be a bug after all!

---Joel

Charlie Edmondson · Mar 8, 2007

Oliver Friedrich wrote:

"Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote in
news:12utro6pck5pb8c@corp.supernews.com:

"Oliver Friedrich" <oliver.friedrich@tzm.de> wrote in message
news:esmngi$p13$1@news.BelWue.DE...

I've discovered a phenomen which I claim to be a fatal PSpice error,
at least something that I don't understand at all.

I doubt it's really a bug in the PSpice "core" per se, but I wouldn't
be surprised if it's a limitation of the transmission line model
PSpice uses, or perhaps the behavioral modeling code. ("Limitation"
implies that the inaccuracies are known and -- somewhere --
documented, whereas "bug" implies something's going on that the PSpice
designers were unaware of.) You're asking PSpice to do the following
here:

1) Accurately model a lossy transmission line. This is challenging to
do correctly in the general case (you still see the occasional journal
papers where people are trying to create better models).
2) Convert the results back to the time domain for your transient
simulation. This is also difficult (in fact, many SPICE simulators
don't even support this feature).

To someone who's been using SPICE simulators for awhile, the fact that
you get an incorrect answer is not too surprising. Of course, you
*should* forward your example to ORCAD support and ask them to tell
you what's going on. I'm still placing my bets on the behavior being
a known limitation rather than a bug...

---Joel

Hallo Joel,

I'm looking forward to get any domentation from you describing this
"restriction".
To me it is an error and nothing else. Don't blandish! The major task of
a simulation model is to simulate its real counterpart as close as
possible. Since you can't model the reality perfectly the most important
information that must be provided with any model is a documentation of
where it is applicable and where it is not applicable. This documentation
must be available and not hidden in a little vague application note on
website xyz of university scoobydoo department PSpice forensics.

These undocumented "features" take away a lot of valuable time from you
and me and everyone. Sure it is inevitable that software has bugs, but
when I discover a bug let me call it a bug.

Sorry if I offended you, it's not your fault, but at the moment I'm angry

Oliver Friedrich
Oliver,

Sorry you found out that simulators are not reality - "the map is not
the territory." In PSpice, the transmission line is done behaviorly,
there is not a DC connection between the input pins and the output pins.
So, you can get very interesting results. One thing you can not
really do is tline filter synthesis and matching. The tool isn't built
for it. The primary goal in PSpice tlines is to match drive impedance,
output impedance, and provide appropriate delays (and getting the delays
close is not a trivial matter, believe you me!) As Jim has pointed out,
the PSpice Reference Guide has all this documented, so it ain't a bug,
just a known limitation of the tool.

Charlie

Oliver Friedrich · Mar 9, 2007

Hallo Jim,

Stop whining and learn the tool, or go flip burgers. RTFM!

ROFL, that's really a cool answer!!

What version are you using? Student or professional?

I'm using professional 10.0 and found something interesting in the mean

time.

Modelling the r of the line

case1: r=342m
no skin effect returns almost the correct answer, slightly different but
for peace sake...

case: r={342m+0*sqrt(s)}
formally modelled with skin effect but set the coefficient to zero.
Obviously should return the same result as case1 but doesn't, give it a
try!
Also, the simulation speed drops to roughly 1/3 of case1 although it
should have to do more work, with all that convolution stuff, shouldn't
it?

I'm getting more and more convinced that this behaviour is unintendet and
unknown, so calling it a bug is still an issue for me!

Finally: Your burger phrase is really great fun and a good lesson for a
german guy to learn cool expressions, but you mustn't think that I'm a
stupid idiot. Sure you're right, and you might get pissed off with all my
complaining, so now I'll stop whining and return to discussion;-)

Looking forward to hear new cool stuff

Oliver Friedrich

Oliver Friedrich · Mar 9, 2007

Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote in
news:4o60v21k76780hugk0h6foav6qctp38gf5@4ax.com:

Page 304, v15.7 Pspice Reference Guide.

...Jim Thompson

Thanks for the advice. Unfortunately I don't have v15.7 hence I don't have
the documentation for it. I'm running 10.0 and this document offers me a
distributed model of a lossy transmission line with

..model TRN(r=1 l=1 g=1 c=1)

The document refers to a paper by Roychowdhury and Pederson that claims to
describe the internal implementation of the behavioural model. So don't
come with RTFM!

There's also a TLOSSY model but not available for PSpice Basics. Do you
mean that?

Oliver Friedrich

Jim Thompson · Mar 9, 2007

On Fri, 9 Mar 2007 12:44:41 +0000 (UTC), Oliver Friedrich
<oliver.friedrich@tzm.de> wrote:

Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote in
news:4o60v21k76780hugk0h6foav6qctp38gf5@4ax.com:

Page 304, v15.7 Pspice Reference Guide.

...Jim Thompson

Thanks for the advice. Unfortunately I don't have v15.7 hence I don't have
the documentation for it. I'm running 10.0 and this document offers me a
distributed model of a lossy transmission line with

.model TRN(r=1 l=1 g=1 c=1)

The document refers to a paper by Roychowdhury and Pederson that claims to
describe the internal implementation of the behavioural model. So don't
come with RTFM!

There's also a TLOSSY model but not available for PSpice Basics. Do you
mean that?

Oliver Friedrich

480)460-2350 | |
| E-mail Address at Website Fax

Oliver Friedrich · Mar 12, 2007

Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote in
news:jjr2v295t3p2iqfebkq24e56fcj5q27fbt@4ax.com:

Hallo Jim,

You don't have to flip burgers after all ;-)

I am really glad to hear that from you!

Finally I have to admit that I was not aware of the great difficulties of
modelling transmission lines. That seems to be an open chapter in the
history uf simulating. So maybe my brain breeds some great innovations in
lossy line modelling while the rest of mine is busy with cooking (burgers?)

Thank you for your help and your humor!

Oliver Friedrich

Big bug in PSpice??

Oliver Friedrich

Guest

Joel Kolstad

Guest

Jim Thompson

Guest

Oliver Friedrich

Guest

Oliver Friedrich

Guest

Jim Thompson

Guest

Jim Thompson

Guest

Georg Baum

Guest

Joel Kolstad

Guest

Charlie Edmondson

Guest

Oliver Friedrich

Guest

Oliver Friedrich

Guest

Jim Thompson

Guest

Oliver Friedrich

Guest

Welcome to EDABoard.com

Sponsor

Online statistics

Forum statistics

Big bug in PSpice??

Oliver Friedrich

Guest

Joel Kolstad

Guest

Jim Thompson

Guest

Oliver Friedrich

Guest

Oliver Friedrich

Guest

Jim Thompson

Guest

Jim Thompson

Guest

Georg Baum

Guest

Joel Kolstad

Guest

Charlie Edmondson

Guest

Oliver Friedrich

Guest

Oliver Friedrich

Guest

Jim Thompson

Guest

Oliver Friedrich

Guest

Log in

Welcome to EDABoard.com

Sponsor