Pspice compatibility: Bus representation in subcircuit calls

[Larry Gipson]

A long while ago when I used Pspice, I recall that it would only
accept curly braces for busses in subcircuit calls. Is this still
true?

So a 5 bit counter with a bus q[0:4], the call might look like this:

Xu1 q{0} q{1} q{2} q{3} q{4} counter

with similar notation on the subcircuit.

Is this still true or have they expanded Pspice now to accept square
backets and so forth?

I use (ECS, Synario) CohesionTools for schematic capture which allows
a range of options to represent bus structures and have always been
able to find something compatible with whatever simulator I'm using.
This is not true with LTspice as it apparently doesn't accept brackets
of any kind that I've found. The only option is to hand edit the
netlist replacing brackets with underscores - or deleting them
altogether. I suppose since the schematic capture in LTspice doesn't
do busses, there was no need to include them in the simulator.

Has there been an update I've missed? Has anyone else run into this?

Regards,
Larry

 

[Mike Engelhardt]

I think you're confusing schematic capture capability
and SPICE syntax. PSpice does sort of accept those curly
braces you're proposing in netlist names, but you can't
plot them from the waveform viewer. It's sort of a bug
you can check out in the attached deck. But PSpice
Schematics does handle busses and it doesn't need curly
braces when it's done resolving netlist names. Busses
in LTspice Schematic capture is an undocumented and
difficult to reach feature, but it does handle them
when they've been drafted in a different CAD tool used
inhouse.

In ECS/Snyario, you should be able to convert your buss
character to be, e.g., an underscore character to create
legal SPICE node names.

--Mike

Here's a deck that shows the limit case:

*
R1 {N002} N001 1K
C1 {N002} 0 .1u
V1 N001 0 pulse(0 1 0 1u 1u .5m 1m)
..tran 3m 3m
..probe
..end

In PSpice, the curly braces are part of the name but
you can't plot V({N002}). In LTspice, the curly
braces are treated as parenthesis and ignored as
they are in PSpice.

 

[Larry Gipson]

I think you're confusing schematic capture capability
and SPICE syntax.

Maybe, but I don't think so. I'm more pragmatic than purist. I just
want things to work more than argue

PSpice does sort of accept those curly

braces you're proposing in netlist names, but you can't
plot them from the waveform viewer. It's sort of a bug
you can check out in the attached deck.

I sort of remember that what you say is true, however, it was possible
to run Pspice with the curly braces and get sims to run correctly. It
was only Probe that was broken.

But PSpice

Schematics does handle busses and it doesn't need curly
braces when it's done resolving netlist names.

When I used Pspice, it ran in a DOS window. There was no such thing
as PSpice Schematics. I used ECS/Scenario at the time, which could be
set to output curly braces. This worked fine as long as you weren't
looking directly at the busses (a long time ago now, so I may be wrong
here).


Busses

in LTspice Schematic capture is an undocumented and
difficult to reach feature, but it does handle them
when they've been drafted in a different CAD tool used
inhouse.

Yet there are many in Linear Technology who use the same schematic
capture I do. (I talked with a fellow in Santa Barbara recently.)
Apparently they use Pspice and LTspice, among others. There's a big
emphasis on low cost PC based tools. They would have the same
limitations I do with the schematic capture.

In ECS/Snyario, you should be able to convert your buss
character to be, e.g., an underscore character to create
legal SPICE node names.

Actually, you can't. At least I haven't been able to do it. In the
latest 6.0 version of Cohesion, they still only allow 4 choices: () <>
{} []. I tried hand editing the appropriate .ini file to select an
underscore and it still defaults to square brackets. I'll suggest
allowing an underscore in their next release - unless you know a work
around.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

Yet there are many in Linear Technology who use the same
schematic capture I do. (I talked with a fellow in Santa
Barbara recently.) Apparently they use Pspice and LTspice,
among others. They would have the same limitations I do
with the schematic capture.

I don't know of anyone in Santa Barbara that uses the
Synario netlister, though they do use their schematic
capture -- not that that's open for public debate.
It would be somewhat exceptional if you can determine you
were using the same schematic capture tools was a Santa
Barbara engineer. Internal tool integration with mfg has
pretty much obscured which products they are using at this
point.

I sort of remember that what you say is true, however,
it was possible to run Pspice with the curly braces
and get sims to run correctly. It was only Probe that
was broken.

You can think of it as a broken Probe, but I think of it
as a slightly broken SPICE lexicon. hspice behaves
similarly with corrupt node names. It would be more
uniform if the curly braces are treated as parenthesis,
as they are in LTspice and elsewhere in PSpice syntax.
However, again, your problem is your Synario netlister.
Or, at least the way you have it set up.

Actually, you can't. At least I haven't been able to do it.

I have always been able to get Synario to put out valid SPICE
node names for busses, but I can't remember how to set it up
to do so. It's an independent matter than which character
you use for busses on the schematic. This is something for
you to take with with Synario. As mentioned, we no longer
use their netlister, but our problems dealt with other issues.

--Mike

 

[Larry Gipson]

You can think of it as a broken Probe, but I think of it
as a slightly broken SPICE lexicon. hspice behaves
similarly with corrupt node names. It would be more
uniform if the curly braces are treated as parenthesis,
as they are in LTspice and elsewhere in PSpice syntax.
However, again, your problem is your Synario netlister.
Or, at least the way you have it set up.

I haven't had a problem with hspice and brackets.

As you know, hspice is the gold standard simulator for ic design.
Neither hspice or smartspice (hspice clone) apparently have a problem
with brackets in subcircuit calls. Here's a page from the hspice
manual:

Using Sources and Stimuli Digital and Mixed Mode Stimuli
Star-Hspice Manual
The bit order is MSB:LSB. This bus notation syntax may also be nested
inside
other grouping symbols such as <>, (), [], etc. The name of each bit
will be
vname with the index suffix appended.
Example 1
If you specify:
radix 2 4
vname VA[0:1] VB[4:1]
the resulting names of the voltage sources generated are:
VA0 VA1 VB4 VB3 VB2 VB1
where VA0 and VB4 are the MSBs and VA1 and VB1 are the LSBs.
Example 2
If you specify:
vname VA[[0:1]] VB<[4:1]>
the resulting names of the voltage sources are:
VA[0] VA[1] VB<4> VB<3> VB<2> VB<1>
Example 3
This example shows how to specify a single bit of a bus:
vname VA[[2:2]]
Example 4
This example generates signals A0, A1, A2, ... A23:
radix 444444
vname A[0:23]


Since they advertise in their manual that hspice can use various
brackets in subcircuit calls, I'll argue this is actually the industry
standard - at least for IC's.

I use smartspice daily, so I know it works with brackets.

I'm not aware of the standard syntax you're referring to, but I'm
guessing it's the original Berkeley code?

I realize you're not trying to make LTspice an hspice clone, but
Cohesion isn't broken. It's just not quite compatible with LTspice
(or vice-versa) in this instance.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

I haven't had a problem with hspice and brackets.

Then I suggest you look at how the names appear in Awave
in the current version of hspice.

Anyway, all you have to do is make node names without
illegal characters in them. Since LTspice accepts different
number of nodes for the same device type(like VDMOS and
SOI), it's confusing to allow substitution command syntax
like braces in node names.

Of course, LTspice does netlist and run internally generated
IC schematics with busses and bus pins, but it converts the
bus resolved names to legal spice node names.

As you know, hspice is the gold standard simulator for
ic design.

I certainly don't know that. hspice has been eclipsed by
other tools. But its syntax for binning certainly is the
standard and is a subset of LTspice binning syntax.

Neither hspice or smartspice (hspice clone) apparently
have a problem with brackets in subcircuit calls. Here's
a page from the hspice manual:
[snip]

Ah, you're expecting SPICE to expand bus names. OK,
generate your netlists with flattened buss names and get
rid of the illegal characters. Case closed.

--Mike

 

[Jim Thompson]

A long while ago when I used Pspice, I recall that it would only
accept curly braces for busses in subcircuit calls. Is this still
true?
[snip]
Has there been an update I've missed? Has anyone else run into this?

Regards,
Larry

See "PSpiceBusNotation.pdf" on the S.E.D/Schematics page of my
website.

...Jim Thompson

 

[Larry Gipson]

A long while ago when I used Pspice, I recall that it would only
accept curly braces for busses in subcircuit calls. Is this still
true?
[snip]
Has there been an update I've missed? Has anyone else run into this?

Regards,
Larry

See "PSpiceBusNotation.pdf" on the S.E.D/Schematics page of my
website.

...Jim Thompson

Thanks Jim.

How does it expand the names in the netlist? Does it maintain the
backets or lose them?

D[1] D[2] or D1 D2 ?

Regards,
Larry

 

[Larry Gipson]

I certainly don't know that. hspice has been eclipsed by
other tools. But its syntax for binning certainly is the
standard and is a subset of LTspice binning syntax.

Actually, nearly every simulator targeted at the ic industry is
concerned about running hspice decks. While it's true hspice is now
one of the slower simulators around, other simulators often advertise
that they're 10x or 20x (or whatever) faster than hspice. Same thing
for accuracy. I don't know if this makes it a standard or not, but
it's pretty close.

Regards,
Larry

 

[Larry Gipson]

nyway, all you have to do is make node names without
illegal characters in them.

The point is what you're saying are illegal and corrupt node names
aren't illegal at all in simulators targeted for the ic design
industry. LTspice isn't meant for this industry that I know of, so I
don't expect it to be compatible.

These node names are likely limited to subcircuit calls in hspice to
accommodate bus structures. Talking with another friend who writes
simulators tonight, I think I understand more what the issue is.

I thought that probably other tools forced the bus structure naming
convention back onto the analog simulators since you point out that
it's not an ideal situation. My friend agreed and thought it was
probably Verilog. Hspice is probably the most compliant of simulators
in this area, allowing all bracket types for subcircuits. They
apparently hand coded a parser to do this. His guess is that you're
probably using a parser generator that insists on a uniform grammar
for all instances of a particular symbol while hpspice can have a
different symbol usage for various components (resistors, capacitors),
including subcircuits. Are we close?

At any rate, my friends simulator gets around the issue by simply
treating square brackets like any letter. D1 and D[1] are unique bus
names and can exist in the same subcircuit call.

I wouldn't expect you to comply with the ic industry "standard" since
your simulator is intended for pc board design. Pspice really isn't
meant to be used in ic design either, but I have used it in the past
and it did do busses correctly. This is the reason the thread is
labeled Pspice and not LTspice. I'm hoping to replace Smartspice
soon.

Regards,
Larry

 

[Larry Gipson]

Ah, you're expecting SPICE to expand bus names. OK,
generate your netlists with flattened buss names and get
rid of the illegal characters. Case closed.

--Mike

Not at all. The schematic capture program does this expansion.

Part of the mismatch in the discussion I think has to do with scale.
I often work on chips so large doing anything with a flattened netlist
is not a practical thing to do.

Perhaps an example might help. I've worked on focal plane array chips
for a number of years now. Most recently I worked on a chip for a
digital camera. This had a very large analog array of 5 megapixels,
analog interface circuits, bias circuits, a charge pump, an adc, and
a large digital control block. The circuit was drawn in Cohesion and
simulated with Smash and smartspice. The schematics rely heavily on
iterated instances and busses.

The approach varies, but the digital stuff on such a chip can be
simulated with a digital simulator and can be described using vhdl.
The analog stuff would be simulated in smaller blocks, then in larger
blocks until the simulations become impractical. Hierarchy and
compatibility between the tools is extremely important.

You certainly wouldn't do anything with a flat netlist on anything
this large. Any subset that would be simulated with an analog
simulator would have to use the same nomenclature for the busses since
that's part of what you're trying to verify.

Hope this helps.

Regards,
Larry

 

[Jim Thompson]

On Fri, 28 Nov 2003 09:28:44 -0800, Larry Gipson

[snip]

See "PSpiceBusNotation.pdf" on the S.E.D/Schematics page of my
website.

...Jim Thompson

Thanks Jim.

How does it expand the names in the netlist? Does it maintain the
backets or lose them?

D[1] D[2] or D1 D2 ?

Regards,
Larry

I've only used buses into a "block", but if I get a moment here I'll
try a subcircuit out and post the resulting netlist.

...Jim Thompson

 

[Mike Engelhardt]

Larry,

Actually, nearly every simulator targeted at the ic
industry is oncerned about running hspice decks. While
it's true hspice is now one of the slower simulators
around, other simulators often advertise that they're
10x or 20x (or whatever) faster than hspice. Same thing
for accuracy. I don't know if this makes it a standard
or not, but it's pretty close.

There are at least two aspects of hspice that I wouldn't
look toward for a standard. One is all that proprietary
device scaling and the other is its node syntax. In my
own view, both features should not be part of the
simulator, but should to be part of the schematic capture
in the interest of more uniform documentation for layout
and verification.

The point is what you're saying are illegal and
corrupt node names aren't illegal at all in
simulators targeted for the ic design
industry. LTspice isn't meant for this industry
that I know of, so I don't expect it to be compatible.

Don't be stupid. LTspice is targeted and used for IC
design. It is also routinely used with large hierarchical
IC designs with busses spanning levels of the hierarchy.
You're just having trouble generating a valid netlist
for it. Support for node names with braces in hspice
and PSpice is partial in that the waveform viewers for
both have trouble with trouble with node names with
curly braces. BTW, usually PSpice interprets curly
braces that weren't used for parameter substitution as
parenthesis and then categorically ignores parenthesis
about node names in the same manner as Spectre. Hspice
uses single quotes for parameter substitution so it has
no potential confusion there, but still corrupts the
name that goes to the viewer. Curly and square braces
with give you different trouble in each simulator.

Not at all. The schematic capture program does this
expansion...You certainly wouldn't do anything with a
flat netlist on anything this large.

Now you're just being arugentative. I never suggested
generating a flat netlist, just flat bus names. Your
hspice manual quote was about using hspice to expand
the bus names, a practice I wouldn't promote.

In any case, you probably shouldn't mix parenthesis types
in hspice. You should run that example I pointed out
in hspice to see what it does with the names. Also,
in PSpice, square brackets about node names are supposed
to be ignored. It's a vintage syntax that allowed string
node names for a bipolar substrate node. Further, if you
netlist the PSpice Schematics examples that have busses,
you don't generate node names with any kind of braces.

--Mike

 

[Jim Thompson]

On Fri, 28 Nov 2003 09:28:44 -0800, Larry Gipson

[snip]

See "PSpiceBusNotation.pdf" on the S.E.D/Schematics page of my
website.

...Jim Thompson

Thanks Jim.

How does it expand the names in the netlist? Does it maintain the
backets or lose them?

D[1] D[2] or D1 D2 ?

Regards,
Larry

Looks like it loses the brackets. I dredged up an old bus test where
I was curious if PSpice would "bus" analog... it does...

See "BusCheck-Block-Netlisting.pdf" on the S.E.D/Schematics page of my
website.

If you are using "Schematics" as the frontend for PSpice I have
pre-made symbols for subcircuits with one to sixteen I/O, just type in
the subcircuit model name and the I/O names and away you go. If you
(or anyone else) would like a copy just let me know.

(If you are using Capture I grieve for you ;-)

...Jim Thompson

 

[Jim Thompson]

Larry,
[snip]
Also,
in PSpice, square brackets about node names are supposed
to be ignored. It's a vintage syntax that allowed string
node names for a bipolar substrate node.

It's to allow 3 *and* 4-terminal bipolar connections. The [node-name]
notation keeps the 4th terminal from being confused with the model
name.

Further, if you
netlist the PSpice Schematics examples that have busses,
you don't generate node names with any kind of braces.

--Mike

Correct, see "BusCheck-Block-Netlisting.pdf" on the S.E.D/Schematics
page of my website.

...Jim Thompson

 

[Mike Engelhardt]

Jim,

It's to allow 3 *and* 4-terminal bipolar connections.
The [node-name] notation keeps the 4th terminal from
being confused with the model name.

That's correct, Jim. I think old versions of PSpice
wouldn't get confused if the substrate node was a
number, since PSpice in those days wouldn't allow
model names to start with a number, like 2N2222 had
to be Q2N2222.

Many SPICE's now look to see if the fourth node
is a bipolar model name, in which case it assumes
it is a model and not a node and therefor the substrate
is connected to ground. This allows to the square
braces to be unambiguously dropped in most cases,
even when the substrate node is some string. The
generic academic codes have made an attempt at this
for some while.

Nowadays, there's several devices that take variable
numbers of nodes, e.g., MEXTRAN and most SOI devices,
so it gets more problematic to allow curly braces in
node names since when the parameter substitution is
done, it isn't yet known if those are nodes or
parameters with the curly braces in them. Also,
there's all those vintage decks that expect the
parenthesis to be ignored.

Correct, see "BusCheck-Block-Netlisting.pdf"
on the S.E.D/Schematics page of my website.

--Mike

 

[Larry Gipson]

If you are using "Schematics" as the frontend for PSpice I have
pre-made symbols for subcircuits with one to sixteen I/O, just type in
the subcircuit model name and the I/O names and away you go. If you
(or anyone else) would like a copy just let me know.

(If you are using Capture I grieve for you ;-)

As I recall Pspice schematics was a pretty fair schematic capture
program. Then I think Orcad bought Pspice and Cadence bought Orcad?

At any rate, the Orcad program hadn't improved much I guess since I
used it years ago. It didn't do hierarchy well from what I heard and
was pretty much unacceptable for IC design. Friends who purchased
Pspice at that time still bought Pspice schematics, which they would
still sell if you asked for it.

What's going on now? Is Orcad any better or are you still using
Pspice schematics. Or did you just tell me?

Is Capture the Orcad?

Regards,
Larry

 

[Jim Thompson]

[snip]

(If you are using Capture I grieve for you ;-)

As I recall Pspice schematics was a pretty fair schematic capture
program. Then I think Orcad bought Pspice and Cadence bought Orcad?

Yep :-(

At any rate, the Orcad program hadn't improved much I guess since I
used it years ago. It didn't do hierarchy well from what I heard and
was pretty much unacceptable for IC design.

OrCAD was great until they tried their own windows thingy, then they
never quite handled the advent of MS Windows. Pure junk!

Friends who purchased
Pspice at that time still bought Pspice schematics, which they would
still sell if you asked for it.

It was still available this last release (10.0i)... you don't have to
ask for it, it's simply hidden under "Custom Installation".

What's going on now? Is Orcad any better or are you still using
Pspice schematics. Or did you just tell me?

I'm still using PSpice Schematics, a *marvelously* easy-to-use
program, with good hierarchical support.

Is Capture the Orcad?

Regards,
Larry

"Capture" is OrCAD/Cadence. The scuttlebutt is that Cadence will stop
PSpice Schematics support at the next release.

If I can't continue to use Schematics as a frontend I will walk.

I simply refuse to have anything to do with Capture... PERIOD!!

...Jim Thompson

 

[Larry Gipson]

Don't be stupid.

Now you're just being arugentative.

I'm having trouble here figuring out who's doing what to whom.

I can certainly be both stupid and argumentative, but please don't
mistake this with the directness of an engineer. I also tend to avoid
name calling on usenet and if I've done that, let me apologize.

Perhaps you could provide an example of a bus structure in LTspice in
your schematic adaptation interfacing with an iterated instance. This
would help to see how it might be used for larger designs.

If your program is targeted for the IC industry, I can't fathom why,
except maybe for internal use. I thought the reason it was being
offered to the masses for free was simply to help sell Linear
Technology products. Since these are already IC's it wouldn't seem to
me to be in their best interest to make a program useful to their
competitors. Again, I apologize if my assumption is wrong.

Regards,
Larry

 

[Larry Gipson]

Your
hspice manual quote was about using hspice to expand
the bus names, a practice I wouldn't promote.

Ah, now I see. Yes, it apparently does this, but it also takes the
expansions. I posted the entire page, but haven't had a case where
I've used unexpanded nomenclature. My point was simply to show
bracket usage in general and not specifically their unexpanded syntax.

The fact that hspice will expand busses in the subcircuit calls is a
curiosity.

Regards,
Larry