Pspice compatibility: Bus representation in subcircuit call

[Mike Engelhardt]

Larry,

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.

I always wonder if conditional apologies mean they're
supposed to be conditionally accepted Anyway OK,
similarly don't mistake my own talk with the directness
of an engineer. My interest there was just to clear up
some false assumptions you've been posting about LTspice
and Linear's inhouse tools. These are matters you can't
possibly have a valid opinion on. You certainly can't
get it from any conversation with an engineer from one
design center. Most design engineers using the tools
are shielded from such netlist details and aren't aware
of what program does the netlisting. It is not
ECS/Scenario/Cohesion, again, not that its any of your
business.

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.

Absolutely not. Busses in LTspice are supported only
in conjunction with other in-house tools. No support
is offered for external use. That being said, all you
have to do is generate a netlist with valid node
names, but I'm apparently wasting my breath. Try
having the schematic capture program you're using
expand the bus node names an convert funny characters
to underscores. Alternatively, just label each node
with a name that doesn't have funny characters in them.
Your schematic capture program should be able to
generate a generic SPICE netlist. Certainly you have
to do that for PSpice if you want to be able to plot
the node names in Probe. As I said in my first post,
I think you're confused between schematic capture and
SPICE capabilities.

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.

LTspice is used both inhouse for IC design and is supported
externally for applying the IC's. We don't waste time
crippling the program for different targets. The license
details when support for external use can be expected. Yes,
some fabless designers are using it a potentially competitive
role. But the frustration LTspice causes valid competitors
makes it worth worthwhile in at least my own personal
opinion for the time being.

--Mike

 

[Jim Thompson]

On 29 Nov 2003 20:24:25 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

Larry,

[snip]

Alternatively, just label each node
with a name that doesn't have funny characters in them.
Your schematic capture program should be able to
generate a generic SPICE netlist. Certainly you have
to do that for PSpice if you want to be able to plot
the node names in Probe.
[snip]
--Mike

Yep, Just avoid naming nodes with \, /, |, >, etc., stay alpha-numeric
....

Just put a marker on the schematic *wherever* it is in the hierarchy.

It'll show in Probe (for example) as I(HB1.V4:2) or V(HB1:BIT0).

Alternatively, all nodes get listed in the "Add Trace" list... just
pick the one you're interested in.

...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.

 

[Larry Gipson]

On 29 Nov 2003 20:24:25 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

I always wonder if conditional apologies mean they're
supposed to be conditionally accepted

Absolutely

Anyway OK,

similarly don't mistake my own talk with the directness
of an engineer. My interest there was just to clear up
some false assumptions you've been posting about LTspice
and Linear's inhouse tools.

Which I have not done. I did speak with a fellow and found out what I
posted. Nothing more or less implied. It was a one liner and is what
it is.

These are matters you can't

possibly have a valid opinion on. not that its any of your
business.

And I could care less?

Here's a thread I'm interested in:

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.

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.

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.

Absolutely not. Busses in LTspice are supported only
in conjunction with other in-house tools. No support
is offered for external use.

LTspice is used both inhouse for IC design and is supported
externally for applying the IC's. We don't waste time
crippling the program for different targets.

In one sentence you claimed one thing and when the point was pressed
you backed off. I simply pointed out that LTspice was not targeted
for ic design (externally) and got called names. As you point out,
the external program is a board level program.

Case closed. - Mike E

You know, I started this thread to find the status of Pspice, not
LTspice. I decided your program was not an acceptable alternative for
my main simulator quite a while ago. Why you thought it was important
to write about LTspice here is beyond me. Since you did . . .

My observations at this point about (external) LTspice and IC's:

1. The LTspice schematic capture for anyone external to Linear
Technology does not do busses and is not appropriate for large mixed
signal designs.

2. The LTspice schematic capture does not do iterated instances, even
thought the ECS/Scenario program it's based on did, making it even
less appropriate for large designs when large arrays are present.

3. Many features of the ECS/Synario program the schematic capture is
based on seem to be missing, making the entire schematic capture
program much less useful than the original.

4. The LTspice schematic capture symbols and schematics are similar
to, but not compatible with, the ECS/Synario/Cohesion tool it was
based on, making simulations from these programs only possible via
netlists. It's possible to port symbols and schematics back and
forth, but not without editing.

5. The simulator easily runs externally generated decks so the
limitations of the schematic capture can be avoided.

6. The simulator gui does not handle hierarchy, but instead relies on
a hard to use regular expression processor. Yuck! Ok for small
files, but a genuine pain for larger circuits.

7. The simulator will not run an hspice deck. Work-arounds are
difficult and incompatible with established tools. (Busses are a good
example.) This can mean a lot of hand edited netlists.

8. The simulator will not run an hspice bsim3 model file without
generating a stream of error messages. (Apparently this doesn't have
much effect on accuracy, but I wouldn't want a customer to see it.)

9. The simulator speed is in the middle of the performance range.
It's faster than hspice and smartspice on many circuits, but way
slower than the fastest simulators now available.

10. The FFT and other features of the gui are great.

11. Tech support is also great.

I'm doing this from memory and haven't kept a written list. If anyone
else has any positive or negative thoughts on the program, please
share. We know Mike is a nice guy, so please keep it technical.

So the big ic simulator companies can sort of rest easy. This one
isn't competition except for price.

One the other hand, it's probably the best thing going for board work,
which is the main intent. Linear Tech and Mike E. have done the
world a great service. They have also pulled the rug out from under
the other board simulator companies.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

Perhaps you could provide an example of a bus structure
in LTspice...
[snip]
In one sentence you claimed one thing and when the
point was pressed you backed off.

The point is that bus support has nothing to do
with the simulator in PSpice or LTspice, but the
schematic capture. While the LTspice schematic
capture can support busses for internal use, we
don't support it for external use. Mostly because
I think the Synario methods it supports are an
abortion and I don't want to support them for the
general population. Just like the Synario
netlister with that wonderful capability to write
attributes as expressions of other attributes, but
then rounding everything to 3 decimal digits. Gag
me with a spoon. Great idea but such a stupid
implementation that I don't document/support for
general use.

...You know, I started this thread to find the
status of Pspice, not LTspice...

Read your post. It's about LTspice and makes
assumptions about it. Read my answer. It gives you
the solution you need to get around your problem.
Also shows the limit case of PSpice and curly braces.
An example that you can run, but can't plot the
waveform or select from its Add Trace command.

...even thought the ECS/Scenario program it's
based on did...

Sorry to be touchy about this type of thing, but
this is not a polite thing to say. LTspice is not
based on ECS/Scenario, it just can read, netlist,
and edit schematics from a modified version of
those tools. I doubt there would be a single
line of source code in common between ECS/Scenario
and LTspice.

6. The simulator gui does not handle hierarchy,
but instead relies on a hard to use regular
expression processor. Yuck! Ok for small
files, but a genuine pain for larger circuits.

The LTspice schematic capture does support hierarchy.
Unlike the ECS/Scenario tools you don't need a
different navigator, just left click a symbol and
enter the sheet(or symbol). You can also cross probe
from any level of the hierarchy. When working without
a schematic, the Add Trace command(not visible trace
command) also supplies a filter similar to hspice's
awave. For IC design from netlists this probably works
better than PSpice's Probe, not nothing like full
cross probing.

--Mike

 

[Larry Gipson]

On 30 Nov 2003 04:36:17 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

Mostly because

I think the Synario methods it supports are an
abortion and I don't want to support them for the
general population.

I really hope that you're successful in imposing your view of spice
industry "standards" on everyone else. It could be that out of sheer
volume you may be able to do this and we'll all be better off and
grateful for your efforts. Until this occurs, other standards exist
that we have to deal with. Denials aside, hspice is one of these
standards.

Read your post. It's about LTspice and makes
assumptions about it.

Actually, no. It's about Pspice. I barely mentioned LTspice in
passing. At any rate, you've taken the entire thread to basically
verify what I said about LTspice in the very first post is true.
Thanks for that, but really not necessary. LTspice was unacceptable
when we started and it's still unacceptable now.

I will, however, remember this experience the next time I think about
buying a Linear Technology product. I did, after all, get called
names by a representative of the company in an open usenet discussion.

We should by now also agree not to call each other stubborn or
ego-centric Or in my case, senile

What I really wanted to know and am still not sure of is this:

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?

The answer to such a question is a simple yes or no. If the answer is
no, then I'll look at other products until the answer is yes. I
decided long ago that Pspice schematics, while a fine program, was not
acceptable for my use. I'm only concerned about the simulator. Jim
pointed out that Pspice schematics does do busses, but simplifies them
in the process such that a subcircuit with both D1 and D[0..1] on it
would run into problems. I don't believe schematics has iterated
instances either.

6. The simulator gui does not handle hierarchy,
but instead relies on a hard to use regular
expression processor. Yuck! Ok for small
files, but a genuine pain for larger circuits.

The LTspice schematic capture does support hierarchy.
Unlike the ECS/Scenario tools you don't need a
different navigator, just left click a symbol and
enter the sheet(or symbol). You can also cross probe
from any level of the hierarchy.

I could care less about your schematic capture and wouldn't waste time
with it. It won't do the larger designs so anything I'd do with it
would be a dead end. I'd have to use an external schematic tool to
run your simulator, however the LTspice simulator doesn't play well
with others.

I'll also stick by my opinion of the regular expression processor in
your simulator gui. It's fine for a few nodes, but I'll look for
something with real hierarchy, thanks.

I've never found cross probing a schematic useful. To me this is a
waste of time. Even after 27 years of design I can still remember a
node name for the 3 seconds it takes to display it on a separate
waveform gui.

I sort of stay away from the push toward integrated tools in general.
I'd rather take a first class tool like Mentor's Calibre program for
lvs and use the best tools I can find (or afford) for the rest. I am
using the cheaper pc based tools for simulation and schematic capture
- whenever possible. I'm presently considering StabieSoft for a
layout tool (linux).

There were, however, some useful features in the old Harris Fastrack
program. For those that don't know, Harris was one of the early
investors in Cadence and had an unlimited license for their tools.
They developed an overlay for the Cadence Edge tool aimed specifically
at the processes their foundry was supporting. This tool was later
simplified to create Analog Artist. The simulator was cdsspice.

One of the things I really liked was the back annotation of currents
and voltages to the schematic. Seeing where all the currents go was
really handy when first setting up a new opamp design or whatever.
There was also a feature where a transistor would have a highlighted
box around it if it was biased incorrectly. This made finding such
devices easy.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

I think the Synario methods it supports are an
abortion and I don't want to support them for the
general population.

I really hope that you're successful in imposing
your view of spice industry "standards" on everyone
else. It could be that out of sheer volume you may
be able to do this and we'll all be better off and
grateful for your efforts.

The trouble with Synario is the need for bus taps
and the fact that two different busses can't have
two bits with the same name and still be distinct
nets, like they could in velum drawings and still
be unambiguous.

Until this occurs, other standards exist that we
have to deal with. Denials aside, hspice is one
of these standards.

Some aspects of hspice are the standard, such MOSFET
binning syntax, but which characters are allowed for
node names is not. There are other propriety aspects
of hspice that preclude it from being a viable standard.
BTW, you never ran the deck in hspice and looked at how
the names actually appeared in awave. My guess is
because you don't even have a copy of hspice to test
these things out. Of course, the impression you don't
have a copy of hspice dates back to when I was helping
you with correcting the the hspice syntax of one of
your netlists calling libraries so that you could run
it in LTspice.

Read your post. It's about LTspice and makes
assumptions about it.

Actually, no. It's about Pspice. I barely mentioned
LTspice in passing.

Larry, you are lying. It's mentioned twice and
spans about half of your original post. And then
you post assumptions about what LTspice can or can't
do and was or wasn't written for, which at first I
ignored and only answered the question you ask, even
posting a example you could even run in PSpice's
demo to verify. You're free to post asinine
assumptions as you choose and I'm free to identify
them as such if I so choose. Welcome to Usenet.

I will, however, remember this experience the next
time I think about buying a Linear Technology product.
I did, after all, get called names by a representative
of the company in an open usenet discussion.

Larry, I only pointed out that you were being
argumentative and saying stupid things. I'm okay
with that. Of course, it does remind me of that
that wisdom from the ancient scripture: "God can't
help you if you're stupid." The wisdom can be found
on reflection on whether "stupid" and "stubborn" were
or were not the same word in ancient language.

--Mike

 

[Larry Gipson]

On 01 Dec 2003 00:00:41 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

The trouble with Synario is the need for bus taps

As I recall, Cadence doesn't use bus taps. Mentor at least used to.
Cohesion is easier to use than Mentor, for sure. I'm not sure what
the point it is, especially when you're program doesn't do them at all
that anyone can verify.

and the fact that two different busses can't have
two bits with the same name and still be distinct
nets, like they could in velum drawings and still
be unambiguous.

The only reason I can think of for having 2 nets with the same name
would be for redundancy in a cable or something. I haven't found this
a problem on chip. It's all the same node to lvs and the simulators.
Give an example?

Regards,
Larry

 

[Larry Gipson]

On 01 Dec 2003 00:00:41 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

Larry, you are lying. It's mentioned twice and
spans about half of your original post.

Here's the post. Where's the lie?


***************** pspice ************************
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
brackets and so forth?

********************* Ecs ******************************

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.


************** LTspice ********************************
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.
************** end of LTspice - all true from here ****************

Like a said, it was a small part of the original post and a throw-away
to me. The only conjecture was identified as such . . . "I suppose .
.. ." It's a fact that LTspice doesn't accept brackets or do busses in
the external version. You've said so many, many times. I gave up
trying to simulate a large file with LTspice after spending about a
half hour hand editing it. (It never ran right.) So what's the
problem? Besides my apparent incompetence at hand editing huge files?

This is hardly worth this sort of lengthy discussion, but it's
starting to be fun.

Regards,
Larry

 

[Larry Gipson]

On 01 Dec 2003 00:00:41 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

Larry, I only pointed out that you were being
argumentative and saying stupid things. I'm okay
with that. Of course, it does remind me of that
that wisdom from the ancient scripture: "God can't
help you if you're stupid." The wisdom can be found
on reflection on whether "stupid" and "stubborn" were
or were not the same word in ancient language.

I'm also having fun letting you go on like this. They took away my
sharp objects long ago, but I really don't understand why Linear lets
you keep an internet access. Hopefully you're gaining more customers
with the program than you lose with the attitude. Geesh Mike, lighten
up a little.

Regards,
Larry

 

[Mike Engelhardt]

and the fact that two different busses can't have
two bits with the same name and still be distinct
nets, like they could in velum drawings and still
be unambiguous.

The only reason I can think of for having 2 nets
with the same name would be for redundancy in a
cable or something.

It was a common practice in velum drafting days.
For example, you have two data busses, read and
write. They both a conductor D3 but are different
nets as they go to different pins on the memory
parts of old. The problem is that the computer
CAD tools don't allow this to be drafted and now
people got used to the artificial limit.

--Mike

"God can't help you if you're stupid."

 

[Larry Gipson]

On 01 Dec 2003 00:00:41 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

My guess is
because you don't even have a copy of hspice to test
these things out. Of course, the impression you don't
have a copy of hspice dates back to when I was helping
you with correcting the the hspice syntax of one of
your netlists calling libraries so that you could run
it in LTspice.

My main simulator is still smartspice. It's an ok simulator at the
core, but things like the fft and other such "features" are lacking.
It gained acceptance in the industry by claiming hspice compatibility
and even has an hspice compatibility mode I don't use. It's more
compatible with hspice models than LTspice is by a long shot. More
important, Silvaco has a device extraction program that some foundries
use. AMIs, for instance, extracts smartspice models directly, then
ports them to hspice, at least a note in their model file says they
do.

I've used a lot of simulators over the years, Mike. Hspice is one of
them. It's one of the simulators I've been thinking about buying.
There's a new(er) waveform viewer based on the Saber viewer (Analogy)
which I'm told is better than Awaves. (Anything has to be better
than hsplot.) What's stopped me so far is the price for the linux
version of the simulator.

-- not that that's open for public debate. Mike E

As I recall, you did find I was using double quotes instead of single
quotes on a library file call. Thanks! Works fine in smartspice, but
not in LTspice or Hspice apparently.

Was this supposed to be some sort of insult?



Regards,
Larry

 

[Larry Gipson]

On 01 Dec 2003 02:52:05 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

It was a common practice in velum drafting days.
For example, you have two data busses, read and
write. They both a conductor D3 but are different
nets as they go to different pins on the memory
parts of old. The problem is that the computer
CAD tools don't allow this to be drafted and now
people got used to the artificial limit.

--Mike

"God can't help you if you're stupid."

Geesh. Talk about an lvs nightmare. Apparently you think this was a
good thing? I'm really glad you're not setting that standard. . .



BTW, are you in marketing?

Regards,
Larry

 

[Mike Engelhardt]

Larry,

It was a common practice in velum drafting days.
For example, you have two data busses, read and
write. They both a conductor D3 but are different
nets as they go to different pins on the memory
parts of old. The problem is that the computer
CAD tools don't allow this to be drafted and now
people got used to the artificial limit.

Geesh. Talk about an lvs nightmare.

But it has nothing to do with lvs. You
still confuse schematic caputure capabilities
with SPICE and lvs. The netlister interfaces
between these. The problem is that the computer
CAD tools don't allow things to be drafted and
now people got used to the artificial limit.

--Mike

"God can't help you if you're stupid."

 

[Jim Thompson]

On 01 Dec 2003 20:02:53 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

Larry,

It was a common practice in velum drafting days.
For example, you have two data busses, read and
write. They both a conductor D3 but are different
nets as they go to different pins on the memory
parts of old. The problem is that the computer
CAD tools don't allow this to be drafted and now
people got used to the artificial limit.

Geesh. Talk about an lvs nightmare.

But it has nothing to do with lvs. You
still confuse schematic caputure capabilities
with SPICE and lvs. The netlister interfaces
between these. The problem is that the computer
CAD tools don't allow things to be drafted and
now people got used to the artificial limit.

--Mike

We still seem to be running in circles. In my mind schematic capture
must be able to do the following things:

(1) Create a netlist readable without ambiguity by the Spice engine.
(2) Yet present a useful visual representation of the circuit...
humanly readable; AND handle hierarchical and bussed designs.
(3) Have a user-friendly GUI to make drawing convenient.
(4) Allow placing "markers" on the schematic that then show waveforms
in an appropriate viewer.
(5) Show operating point data (voltages and currents) directly on the
schematic, for debugging, if desired.
(6) Be able to produce LVS netlists in formats readable by many layout
tools.

PSpice Schematics can do *all* of the above ;-)

...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.

 

[Mike Engelhardt]

Jim,

But it has nothing to do with lvs. You
still confuse schematic caputure capabilities
with SPICE and lvs. The netlister interfaces
between these. The problem is that the computer
CAD tools don't allow things to be drafted and
now people got used to the artificial limit.


We still seem to be running in circles. In my mind schematic capture
must be able to do the following things:

(1) Create a netlist readable without ambiguity by the Spice engine.
(2) Yet present a useful visual representation of the circuit...
humanly readable; AND handle hierarchical and bussed designs.
(3) Have a user-friendly GUI to make drawing convenient.
(4) Allow placing "markers" on the schematic that then show waveforms
in an appropriate viewer.
(5) Show operating point data (voltages and currents) directly on the
schematic, for debugging, if desired.
(6) Be able to produce LVS netlists in formats readable by many layout
tools.

PSpice Schematics can do *all* of the above ;-)

That is a good list. I certainly hope I never
implied anything in contradiction to it. My own
focus was on it "(1) Creating a netlist readable
without ambiguity by the Spice engine", and then
differentiating that from the SPICE engine itself.

I realize that I throughly pissed Larry off. What
it is. But, I don't think Larry has justification
to get excited after he makes false claims about
LTspice from wrong conclusions about what
schematic capture is used in house. The Snynario
netlister does not meet your list requirements and
we don't use it. I thought it was pretty stupid to
draw conclusions about what LTspice can do from a
netlister that is only used with LTspice by Larry
to the best of my knowledge. In general, I don't
see an excuse for a netlister not to be able to
make correct syntax netlists for different SPICE
programs and LVS either; and I specifically don't
see an excuse for drawing conclusions about
different tools from using a netlister that isn't
intended to work with them.

Larry's used LTspice as his simulator for IC
design and I've even helped him in the past with
generating correct hspice syntax so that he could
run TSMC(I think they were) libraries in LTspice.
Now he wants to invoke the psychology of the
customer being always right when he is not a
customer in the remotest interpretation. And
he's difficult to work with because he doesn't even
have hspice to try out the stuff I suggest so he
can see what's really what in the intermediate
syntax. While I don't much care what fabless IC
design concerns do with LTspice, I do find it
disingenuous to post stupid assumptions based on
a lame netlister in response to someone answering
his questions with a clear concise example that
illustrates the thing he needs to know to solve
his problem.

--Mike

 

[Larry Gipson]

mostly from Jim:

We still seem to be running in circles. In my mind schematic capture
must be able to do the following things:

(1) Create a netlist readable without ambiguity by the Spice engine.
(2) Yet present a useful visual representation of the circuit...
humanly readable; AND handle hierarchical and bussed designs.
(3) Have a user-friendly GUI to make drawing convenient.
(4) Allow placing "markers" on the schematic that then show waveforms
in an appropriate viewer.

I agree, except for this. I find it unnecessary. This is simply
preference.

(5) Show operating point data (voltages and currents) directly on the
schematic, for debugging, if desired.

I miss this.

(6) Be able to produce LVS netlists in formats readable by many layout
tools.

PSpice Schematics can do *all* of the above ;-)

Except I don't believe it does iterated instances, does it? If you
don't do large arrays, you don't need it.

I got used to the Cadence Edge program years ago which I think was a
lot better than the current Opus or whatever. At any rate, I looked
for pc based software that had the key features I used in Edge. I
like the way Cohesion deals with arrays and busses (just like Edge
basically).

It's possible to make an 8k x 8k array of cells with 3 levels of
schematics: one for x, one for y, and the cell itself. The bus
structure lets you connect a unique line to each cell for addressing
and at the same time connect a single line shorting all the cells for
power and common row or column select lines. In 6.0, they improved
the bus structures to allow an intermediate breakout and reconnect
between busses.

You can also highlight a node at the top level and follow it up and
down the hierarchy to verify connectivity. I used this a lot on large
chips in Edge and still use it in Cohesion. The limitation is that in
Edge, each successive node selected would be a different color. In
Cohesion, all selected lines are the same color.

I use names and globals a lot for connectivity to simplify schematics.
This highlighting can really help spot a misspelled node.

[LTspice schematic will also highlight a node, but seems to only
highlight a single node at a time. Highlighting the next node seems
to deselect the previous one. I didn't find a way around this.]

Archiving is another important feature I like. Cohesion allows the
user to set up libraries anywhere they want. There's a master.ini and
a local.ini to set up pointers to these libraries. At the end of a
design, I archive everything to a single directory for storage.
Otherwise schematics become useless as libraries change. Cohesion
will also archive the executables so that you can always open the
schematic without invoking the main software. I send these archives
to customers along with the gds at the end of a job as part of the
documentation.

I've used Cohesion for a decade in it's various forms as
ECS/Synario/CohesionTools. The guys are friendly and great to deal
with.

It's is a viable work-around if you lose Pspice Schematics eventually.
It will output a Pspice compatible deck with all the trimmings. . If
you select {} for busses, pspice runs, but may or may not allow you to
look at these busses in probe. (Probably not, since Pspice schematics
loses the brackets. )

Since Cohesion is a separate schematic capture, it won't back annotate
or cross probe with Pspice, though I understand the code is there on
the Cohesion side to do this. If you need this, you'll have to look
elsewhere.

http://www.cohesiontools.com/

Another program I've been looking at is Smash from Dolphin:

http://www.dolphin.fr/medal/smash/smash_overview.html


Smash started out fairly economical, but has gotten more and more
expensive. They started with the Cohesion 5.1 schematic capture, but
recently are offering an additional alternative I haven't seen. They
back-annotate, cross probe and all that stuff as I recall. They are
French, though, so the culture is different. I'm told they can be
hard to deal with. That must be after the sale though, because I've
never seen this. I have friends that use Smash that really like it.
They use the vhdl front end to control analog sims in large mixed mode
designs.

That is a good list. I certainly hope I never
implied anything in contradiction to it. My own
focus was on it "(1) Creating a netlist readable
without ambiguity by the Spice engine", and then
differentiating that from the SPICE engine itself.

Regards,
Larry

 

[Larry Gipson]

On 01 Dec 2003 21:30:58 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

I realize that I throughly pissed Larry off.

Not at all. I have actually been enjoying this, hoping to learn
something. So far I've learned you seem to think you're God. . .

"God can't help you if you're stupid." Mike E

What

it is. But, I don't think Larry has justification
to get excited after he makes false claims about
LTspice from wrong conclusions about what
schematic capture is used in house.

Not this again. Who's making false claims?

The Snynario

netlister does not meet your list requirements and
we don't use it.

Linear Technology may not use it, but there's nothing wrong with the
netlisters in Cohesion. They've performed flawlessly for over 10
years in the various forms. The designers said once the database is
actually organized in the same way a spice netlist is. The result is
I can netlist a design instantly in Cohesion that would take several
minutes in Edge.

The software will output both hierarchical and flat netlists. The
hierarchical netlister as options to output Berkeley Spice, Pspice,
Hspice, LVS, and CDL. It also has a pretty cool option that does
essentially what Jim's work-around does for pulling in supplied
subcircuits. Make a dummy cell with the same name as the subcircuit
and put the subcircuit netlist in the local directory. Every time you
netlist, it automatically pulls in the subcircuit.spi file.

The flat netlister is similar.

The software also has provisions for vhdl, edif, and verilog.

I thought it was pretty stupid to

draw conclusions about what LTspice can do from a
netlister that is only used with LTspice by Larry
to the best of my knowledge.

I don't use LTspice for design and never will. I wouldn't recommend
it for serious work to anyone else. There are far too many negatives
which have nothing to do with someone elses netlister.

In general, I don't

see an excuse for a netlister not to be able to
make correct syntax netlists for different SPICE
programs and LVS either; and I specifically don't
see an excuse for drawing conclusions about
different tools from using a netlister that isn't
intended to work with them.

More vinegar from Mike about a program he's taken as the basis of his
schematic capture. Imitation is, I hear, is the highest form of
flattery. The problem isn't that he copied the wrong program. The
problem is he's botched key features in it that are really useful.
He's also made his version incompatible with the original without
extensive editing - making it impossible to easily go back and forth
to his simulator with the exception of using a spice netlist.

After making the schematic capture unusable for many applications, he
picks on a program that is usable - the one he started with.

Vision? He's heard of it.

Larry's used LTspice as his simulator for IC
design and I've even helped him in the past with
generating correct hspice syntax so that he could
run TSMC(I think they were) libraries in LTspice.

I would never use LTspice in a design. I did do an eval, then decided
it wouldn't do what I need it to do. You (Mike) helped on occasion
with questions and I thank you. On the other hand, the binning in
LTspice wasn't working properly and you fixed it. Again I thank you.
I always give credit where credit is due.

You can also count on me for negative feedback when you start going
nonlinear.

I did use LTspice once as one of 4 simulators for a data point in a
small design verification. The actual design task was done on Mako
and smartspice. Hspice was the other simulator used for this
verification.

ONCE AND FOR ALL:

I DON"T USE THE LTSPICE SIMULATOR FOR DESIGN!!

NEVER DID!! NEVER WILL!!

THE SCHEMATIC CAPTURE IS PURE CRAP!!

get it?

Now he wants to invoke the psychology of the
customer being always right when he is not a
customer in the remotest interpretation. And
he's difficult to work with because he doesn't even
have hspice to try out the stuff I suggest so he
can see what's really what in the intermediate
syntax.

Maybe you have time for these simulation exercises, but I don't. I
have all the access I need to hspice, but I'm done looking at
LTspice.

LTspice is ok for a first cut at small circuits, but that's about it
in my opinion.

I don't think it would save me time to capture an opamp in LTspice
for development, then recapture it in another tool, so I've deleted it
from most machines.

While I don't much care what fabless IC

design concerns do with LTspice, I do find it
disingenuous to post stupid assumptions based on
a lame netlister in response to someone answering
his questions with a clear concise example that
illustrates the thing he needs to know to solve
his problem.

More vinegar.

The online update in LTspice is actually a major drawback for any
design shop. While great, it can make older schematics useless.
There's no guarantee and no archive that I found. You'd have to
routinely back up the various versions of the program to be safe. I
hate updating software in the middle of a design, anyway. Imagine
using this with a design group and getting this sort of cooperation
from your employees. I didn't see a way to deal with this. Combined
with the poor documentation, the cost for using this program could be
high, indeed.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

But, I don't think Larry has justification
to get excited after he makes false claims about
LTspice from wrong conclusions about what
schematic capture is used in house.

Not this again. Who's making false claims?

You are. You claimed (i) that this
thread wasn't about LTspice but you
spent as much time talking about it as
anything else in your original post.
You claimed (ii) that LTspice isn't
intended for IC design. This is false.
And you claim (iii) that LTspice didn't
do busses. But there the problem is the
netlister. Buss don't really have anything
to do with the simulator, but the schematic
capture and netlister.

In contrast, my statements in this thread
have been correct.

The Snynario netlister does not meet your
list requirements and we don't use it.

Linear Technology may not use it, but there's
nothing wrong with the netlisters in Cohesion.
They've performed flawlessly for over 10
years in the various forms.

Actually, it probably is possible to get the
Cohesion netlister to generate a correct
PSpice/LTspice netlist with busses in the
schematic, but I haven't done that since
ECS241 so I can't remember how to do it.
It'd be something for you to take with with
Cohesion as I've advised. But the Cohesion
netlister couldn't netlist gates without
the power pins being drawn on the schematic
and it couldn't globally shrink designs and
generate a netlist for generic SPICE's and
LVS that agreed. Also, it couldn't optionally
netlist transistor instances as intrinsic
SPICE devices or subcicuits to allow simulation
accuracy to be controlled over different parts
of the schematic. These are the sorts of
capabilities that get important with large
mixed mode IC designs and precluded using
Cohesion's netlister.

--Mike

 

[Larry Gipson]

On 02 Dec 2003 16:19:08 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

You are. You claimed (i) that this
thread wasn't about LTspice but you
spent as much time talking about it as
anything else in your original post.

Read the post. It's in your mind.

You claimed (ii) that LTspice isn't
intended for IC design. This is false.

The simulator and schematic capture are intended for the board
community. That's a fact. If it weren't, Linear Technology wouldn't
be using it as a sales tool and wouldn't provide symbols for their
products in the download. If this is something other than a corporate
sales pitch, then port it to linux and release it under the gpl. Open
source.

And you claim (iii) that LTspice didn't
do busses.

And it doesn't. There's no support for busses in the schematic
capture at all and the subcircuit call doesn't support other industry
standards for busses. You can force work-arounds for this internally,
but this is a potential problem for those external people who have to
work with others.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

You are. You claimed (i) that this
thread wasn't about LTspice but you
spent as much time talking about it as
anything else in your original post.

Read the post. It's in your mind.

Fascinating viewpoint. I certainly do
see it talk about LTspice as much as
anything else and attempts to deny that
lame.

You claimed (ii) that LTspice isn't
intended for IC design. This is false.

The simulator and schematic capture are
intended for the board community. That's
a fact.

You are completely mistaken. The LTspice
simulator is indeed intended at least equally
for IC design. It also does the board level
extremely well. The simulator's IC simulation
capabilities aren't crippled for the board-
level work. But the schematic capture
indirectly is, in that those features are
undocumented so most people, such as yourself,
can't access them. The lack of documentation
there isn't to prevent people from using it,
it's just that there are many aspects of the
schematic capture tools it interfaces to that
are below the quality of the rest of LTspice.

If it weren't, Linear Technology wouldn't
be using it as a sales tool and wouldn't
provide symbols for their products in the
download. If this is something other than
a corporate sales pitch, then port it to
linux and release it under the gpl. Open
source.

LTspice already is ported to Linux. But the
source code is extremely valuable I don't
don't expect it ever to be released to the
public any sooner than the source to hspice
or Spectre is. There's a great deal of
original SPICE work in LTspice. "release it
under the gpl?" You sound like a socialist
with a complete disregard for ownership.

And you claim (iii) that LTspice didn't
do busses.

And it doesn't.

The LTspice simulator certainly does. The
schematic capture doesn't for public use,
but that's a non-issue here. The problem is
your mistaken burden of responsibility. If you're
the one integrating a schematic capture to
a simulator, than any incompatibilities are
your problem, not necessary the schematic
capture's or simulator's. Proof that the
LTspice simulator handles busses comes from
the fact that it does it just fine for large
IC designs drafted in methodologies far beyond
those available in Synario.

...subcircuit call doesn't support other industry
standards for busses...

You still haven't run that test case that shows
the limits of this assumption. Anyway, I don't
recommend passing judgment on a simulator one
way or the other based on what it accepts as
legal characters in node names. You will find
cases that certain odd-ball characters are only
partially supported.

In contrast to you, my statements in this thread
have been true.

I realize that I throughly pissed Larry off.

Not at all. I have actually been enjoying this,
hoping to learn something. So far I've learned
you seem to think you're God. . .

This is similar to the problem of how fast to
you have to be to get away from the bear. You
don't have to be able to run faster than the bear,
you just have to faster than the friend you're with.
Similarly, I don't have to be as smart as God,
I just have to be smarter that you

--Mike

"God can't help you if you're stupid."