Big bug in PSpice??

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:

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

Jim Thompson wrote in news: snipped-for-privacy@4ax.com:

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

"Joel Kolstad" wrote in news: snipped-for-privacy@corp.supernews.com:

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

Use part name "TLOSSY"

Part "T" is idealistic

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

What version are you using? Student or professional?

...Jim Thompson

Page 304, v15.7 Pspice Reference Guide.

...Jim Thompson

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

Hi Oliver,

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.

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

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

Hallo Jim,

ROFL, that's really a cool answer!!

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

Jim Thompson wrote in news: snipped-for-privacy@4ax.com:

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

Aha! So you don't have the non-behavioral model.

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

...Jim Thompson

Jim Thompson wrote in news: snipped-for-privacy@4ax.com:

Hallo Jim,

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