ARTIST 2.4 - why do they do this stuff
Larry Lewicki
so I'll apologize in advance if these topics have been covered already.
I have been somewhat amazed at how difficult a menu-driven system can
be made to operate and I am wondering - am I missing something (besides
patience). Some of the "features" that I find particularly "non-intuitive"
are:
- A user should not be allowed to accidentally (or intentionally) put two
identical devices on top of one another. I spent several hours tracking
down a ridiculously high systematic offset in an amplifier only to find
(by looking at the output file) that I had inadvertantly copied two
devices ontop of each other. I know several other more experienced
users that have had the same problem. There should be some sort of warning.
- Why did Cadence choose flat-netlisting. This causes many difficulties -
for example when I look at a plot in 2 months how will I remember what
I(M72,D) or I(Q62,C) is when there are no devices that are listed in my
schematic with these names. I can't even remember what is in my calculator
locations (all 10 of when I run parametric sweeps). I know that this
will be *fixed in OPUS* but I am running on a SPARC 2 which is already
too slow and it only gets slower with OPUS. Anyway, this state of affairs
has already gone unfixed for almost 4 years yet is seems to be a glaring
mistake in "human factors".
- When listing the operating point of devices - (besides the fact that because of
flat netlisting - the names have changed and you don't know which device is
which) the lists should be vertical so that similar parameters on different
devices will line up horizontally (i.e. Vds or Id) so that the list can
be scanned and any anomalies will show up. This is why SPICE files list the
operating point this way. SPICE hardcopies have evolved - they aren't
perfect but there is a reason that things are the way they are.
- The anchor/slider method of getting data from a output waveform is really
inefficient. Even with the output really magnified it is difficult to
put the slider on "exactly" the time point or frequency point that you
want a value from.
- And when you run parameter sweeps it's even worse because
even if you have 5 waveforms on the same screen you can only measure data
for 1 of them!!!! How can you compare settling times (.01%) by eye?
Didn't the "designers" of this system use this stuff before they released
it to the field. This bug still exists after 4 years. (It would be nice
to keep the data and actually run FFTs on waveforms with different conditions
and see how the harmonic distortion varies with say input amplitude or supply.)
- It is relatively easy to do an "OPLOT" of one expression versus another.
I typically use this type of plot to look at interstage linearity of an
amplifier. I would like to get OPLOT outputs for parameter sweeps - but
Artist requires that the x-axis only be time or frequency. Why? It seems
that any type of simulation that you can do for one set of variables should
be feasible in a parameter sweeping fashion.
- Why are the number of points kept during a parameter sweep constrained to
250 (not my lucky number) - why can't the user define this?
- The plot "strips" should be selectable from the parameter sweep menu. If
you want to print out another calculator memory value on another strip to
compare results you have to find a menu that has the plot strip selector on
it (uses additional keystrokes).
- Why can't the user zoom more than one "strip" simutaneously? When looking
at gain/phase relationships typically I have gain on one strip and phase on
another trying to zoom both to the same frequency coordinates (it also happens
with transient responses if you have voltages on one strip and currents on
another) is very difficult. There should be a ZOOM x coordinates of all strips
command.
- When zooming freqency - the simulator doesn't let you look at less than a
decade of frequency. WHY NOT! This is useless when designing crystal oscillators.
The designer must revert back to printing out the outputs and comparing
gain to phase.
- When you pan while viewing a "strip" the pan moves to the next section of the
waveform without any overlap. It should only move, perhaps, 80% so that you
can see where you have been - or maybe better is to allow panning to a point.
The way it is now, the user has to zoom completely out and then back in
in order to find the section of data that is of interest.
- The waveform analysis tool only computes the settling time for nodes that you
point to - this is useless for fully differential amplifiers where the output
is the difference of two nodes. It also is useless if the output of an amplifier
is current not voltage (typical for interstage amplifiers). The logical
extension of this tool is to allow it to operate on values stored in the calculator.
Not just nodes that you point to in the schematic.
I hope that this list doesn't seem overly inflamatory but after using Artist for about
a month my conclusion is that CADENCE has only finished about 80% of the design.
There seem to be so many nagging wierd human factors issues that I can only wonder
*why* were they left in. I feel like I am driving a car (designed by someone that
never has driven - but has watched people drive in the movies so they seem like
they know what's going on) that has oval tires - not quite square - but definitely
not round - and the speedometer is in mph while the odometer is in metric units and
you can only read the fuel gauge at the top of the hour and if you program a
new radio station in - all the other previously recorded ones disappear. In other
words, things kind of work but not smoothly. I am not sure that this is the
productivity improvement that I was expecting.
Maybe the only way for this to improve is for a Cadence software developer (not an AE
that communication path doesn't seem to work well enough) to sit down with me for a
couple of days and see how a circuit designer actually uses this tool.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer - These are not the opinions of National Semiconductor - yet. But
I'm working on it.
---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Larry Lewicki National Semiconductor
l...@galaxy.nsc.com Data Acquisition Products
(408)-721-3469 Santa Clara, CA
Fax: (408)-721-7321
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
James W. Swonger
In article <C9vnH...@voder.nsc.com> l...@galaxy.nsc.com writes:
>
>- A user should not be allowed to accidentally (or intentionally) put two
> identical devices on top of one another. I spent several hours tracking
> down a ridiculously high systematic offset in an amplifier only to find
> (by looking at the output file) that I had inadvertantly copied two
> devices ontop of each other. I know several other more experienced
> users that have had the same problem. There should be some sort of warning.
>
You can place anything you want anywhere you please. To add a feature
that will check whether anything's exactly underneath your proposed
instance would just add complexity. There're properties that tell you
if an item is a multiple instance, and when you select an object
the GraphicsEditor stat command will tell you how many instances are
selected, among other things.
>- Why did Cadence choose flat-netlisting. This causes many difficulties -
> for example when I look at a plot in 2 months how will I remember what
> I(M72,D) or I(Q62,C) is when there are no devices that are listed in my
> schematic with these names. I can't even remember what is in my calculator
> locations (all 10 of when I run parametric sweeps). I know that this
> will be *fixed in OPUS* but I am running on a SPARC 2 which is already
> too slow and it only gets slower with OPUS. Anyway, this state of affairs
> has already gone unfixed for almost 4 years yet is seems to be a glaring
> mistake in "human factors".
>
The netlist is flat because SPICE2 and cdsSPICE which derives from
SPICE2 is a flat simulator.
You should see what facilities you have for backannotation of
simulator device names onto your schematic. In our design system
this is done with additional properties and code. A pencil works
too.
>- When listing the operating point of devices - (besides the fact that because of
> flat netlisting - the names have changed and you don't know which device is
> which) the lists should be vertical so that similar parameters on different
> devices will line up horizontally (i.e. Vds or Id) so that the list can
> be scanned and any anomalies will show up. This is why SPICE files list the
> operating point this way. SPICE hardcopies have evolved - they aren't
> perfect but there is a reason that things are the way they are.
>
I take it this is about the bad column wrapping. Seems to be a
difference in the way FORTRAN-based output routine somewhere in the
guts signals end-of-line and what normal terminals like to see.
Set WRFLAG=1 some time and see more of it.
>- The anchor/slider method of getting data from a output waveform is really
> inefficient. Even with the output really magnified it is difficult to
> put the slider on "exactly" the time point or frequency point that you
> want a value from.
>
This is supposed to be like the controls of a digitizing scope or
something I figure. If you already know the time/freq/voltage
point you want, just use set and print.
>- And when you run parameter sweeps it's even worse because
> even if you have 5 waveforms on the same screen you can only measure data
> for 1 of them!!!! How can you compare settling times (.01%) by eye?
> Didn't the "designers" of this system use this stuff before they released
> it to the field. This bug still exists after 4 years. (It would be nice
> to keep the data and actually run FFTs on waveforms with different conditions
> and see how the harmonic distortion varies with say input amplitude or supply.)
You can write all kinds of utility routines in the cdsSpice command
language to measure all kinds of things. The pretty user interface
is for people who want an appliance rather than a tool box. If
you want to keep and manipulate data from previous runs for
comparison to this ones, nobody's stopping you. Expecting the
simulator to save an arbitrary, indefinite number of output value
arrays in case you might want to go back and look at them is a bit
unreasonable. The plot is derived from the value array, as is the
slider/anchor info. The info doesn't come from the plot.
>
>- It is relatively easy to do an "OPLOT" of one expression versus another.
> I typically use this type of plot to look at interstage linearity of an
> amplifier. I would like to get OPLOT outputs for parameter sweeps - but
> Artist requires that the x-axis only be time or frequency. Why? It seems
> that any type of simulation that you can do for one set of variables should
> be feasible in a parameter sweeping fashion.
>
Looks like this complaint confuses OPLOT with WPLOT, or the Artist
button automatically appends the analysis domain info as the X axis.
If you want to get OPLOTs of a result vs parameter >loops< - since
it's impossible to >sweep< a parameter - you have to pick off your
parameter of interest, stuff it into an array, stuff the loop
parameter into a parallel array (vectors) and oplot the two against
each other.
>- Why are the number of points kept during a parameter sweep constrained to
> 250 (not my lucky number) - why can't the user define this?
>
On the other hand, why would you need such granularity? I expect
somebody decided that more than 250 variations was going to tax
either available memory, disk space or patience. If you want to
loop through 1.2E8 parameters you can do it within cdsSpice.
Again, you have to abandon the user interface. If you don't like
what's on the menu, you've got to make your own sandwich.
>- The plot "strips" should be selectable from the parameter sweep menu. If
> you want to print out another calculator memory value on another strip to
> compare results you have to find a menu that has the plot strip selector on
> it (uses additional keystrokes).
>
If this is really a common problem I suggest that you determine the
sequence of command steps executed by the system (log file, or write
them down as they appear) and make your own modified menu. However
I think if you get to know the simulator you'll just write a
suitable .s file or 12.
>- Why can't the user zoom more than one "strip" simutaneously? When looking
> at gain/phase relationships typically I have gain on one strip and phase on
> another trying to zoom both to the same frequency coordinates (it also happens
> with transient responses if you have voltages on one strip and currents on
> another) is very difficult. There should be a ZOOM x coordinates of all strips
> command.
>
>- When zooming freqency - the simulator doesn't let you look at less than a
> decade of frequency. WHY NOT! This is useless when designing crystal oscillators.
> The designer must revert back to printing out the outputs and comparing
> gain to phase.
>
>- When you pan while viewing a "strip" the pan moves to the next section of the
> waveform without any overlap. It should only move, perhaps, 80% so that you
> can see where you have been - or maybe better is to allow panning to a point.
> The way it is now, the user has to zoom completely out and then back in
> in order to find the section of data that is of interest.
>
>- The waveform analysis tool only computes the settling time for nodes that you
> point to - this is useless for fully differential amplifiers where the output
> is the difference of two nodes. It also is useless if the output of an amplifier
> is current not voltage (typical for interstage amplifiers). The logical
> extension of this tool is to allow it to operate on values stored in the calculator.
> Not just nodes that you point to in the schematic.
>
All the calculator does is pick off node names and add operands or
operations as you specify, and then pipe them to the appropriate
cdsSpice plot/print command.
If you see that the nodes are 101 and 107 (see what the plot label
says, or backannotate, or whatever) then you just make up a loop
file to check settling time(differential) like so
get tran
set time=200n finalv=v(101)-v(107)
loop time from 200n to 0 by -0.1n
set timev=v(101)-v(107)
if abs(timev-finalv)/finalv>0.0001 then break
endloop
set tsettle=time
print tsettle
then put it in a file called tsettle.s in your simulation run
directory, and enter
tsettle
in the simulator input window. Bang. Settling time appears in the
output window. For parameter loops, stuff tsettle in an array or
output file instead.
>I hope that this list doesn't seem overly inflamatory but after using Artist for about
>a month my conclusion is that CADENCE has only finished about 80% of the design.
>There seem to be so many nagging wierd human factors issues that I can only wonder
>*why* were they left in. I feel like I am driving a car (designed by someone that
>never has driven - but has watched people drive in the movies so they seem like
>they know what's going on) that has oval tires - not quite square - but definitely
>not round - and the speedometer is in mph while the odometer is in metric units and
>you can only read the fuel gauge at the top of the hour and if you program a
>new radio station in - all the other previously recorded ones disappear. In other
>words, things kind of work but not smoothly. I am not sure that this is the
>productivity improvement that I was expecting.
>
>Maybe the only way for this to improve is for a Cadence software developer (not an AE
>that communication path doesn't seem to work well enough) to sit down with me for a
>couple of days and see how a circuit designer actually uses this tool.
>
FFC of the design system ever providing the full flexibility of
the native simulator language via menu picks. The menu stuff is
simply canned routines they thought you might find useful. If
they're not, you've got to make your own. Everything the menu
stuff does is by piping command strings to a cdsSpice background
job and then redirecting the output stream. Do you know that if
you type "wplot v(101)" in the simulator input window it'll come
up in the plot window?
cdsSpice also runs standalone. It supports terminal graphics of
several types - VT series, TEK, even a TEKwindow which appears
to be what the graphics head uses. Since I'm quite familiar with
the terminal mode I tend to use the head only for capture and
things which truly require interaction with the schematic; for
optimization of a fixed topology I either write/run/walk away
a batch job or leave my VT240 running overlay plots to look at
later. Sitting and poking one parameter at a time at the head
is a big time-waster and a common trap for new users. The
fascination with the instrument makes people not even think about
what they really want to do; they just accept the menu boundaries
as real. A batch job can do the thinkin' while you go drinkin',
if you set it up right.
Of course it helps to have been using the simulator in native mode
for ten years and have built up a large collection of macros, .s
files and basic techniques for storing and manipulating data.
No reason for you not to start now though. The cdsSpice manual
has a lot of good info on commands. However a lot of the syntactic
nuances and things like parameter passing, etc. are not discussed
in detail. The language is pretty straightforward though and easily
mastered once you pick up a few examples to cannibalize.
--
##########################################################################
#Irresponsible rantings of the author alone. Any resemblance to persons #
#living or dead then yer bummin. May cause drowsiness. Alcohol may inten-#
#sify this effect. Pay no attention to the man behind the curtain. Billy!#
Howard Wilson VW Microbus-R-Us!
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Larry Lewicki National Semiconductor
>l...@galaxy.nsc.com Data Acquisition Products
> (408)-721-3469 Santa Clara, CA
>Fax: (408)-721-7321
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Everything deleted!
Welcome to Cadence Larry!!
--
Howard Wilson Supercomputer Systems Division
Intel Corporation Technology Development - Component Technology
5200 NE Elam Young Parkway MS CO5-01 Email: hwi...@ssd.intel.com
Hillsboro, OR 97124 Phone: 503-531-5056
Syed Zaeem Hosain
>I'm new to this newsgroup and recently (~4weeks) have started using Artist
>so I'll apologize in advance if these topics have been covered already.
>I have been somewhat amazed at how difficult a menu-driven system can
You might try defining keys for yourself as you get more familiar with
the system. This has proven to be much more useful in general.
>be made to operate and I am wondering - am I missing something (besides
>patience). Some of the "features" that I find particularly "non-intuitive"
>are:
>
>- A user should not be allowed to accidentally (or intentionally) put two
> identical devices on top of one another. I spent several hours tracking
> down a ridiculously high systematic offset in an amplifier only to find
> (by looking at the output file) that I had inadvertantly copied two
> devices ontop of each other. I know several other more experienced
> users that have had the same problem. There should be some sort of warning.
Yes, there should be a warning or something - this bit designers at the
last company I worked for. Solution: write some skill code to check for
this condition and invoke it automatically at schematic save time. (I
apologize for calling this a "solution" - a better phrase would be
"customer-developed-workarounds-for-Cadence-bugs/irritations" - we
wrote many of these).
>- Why did Cadence choose flat-netlisting. This causes many difficulties -
Maybe they don't have real designers using these tools internally? This
has been a sore point for many people over the years.
> I know that this
> will be *fixed in OPUS* but I am running on a SPARC 2 which is already
> too slow and it only gets slower with OPUS. Anyway, this state of affairs
> has already gone unfixed for almost 4 years yet is seems to be a glaring
> mistake in "human factors".
Not to mention a *major* productivity and documentation hit - imagine
coming back to work on a chip to make changes later on and having to
wade through a flat netlist.
At my last company, we started using Cadence Edge many years ago (1986
or 1987?), and bugged Cadence for a true hierarchical netlister right
from the start. After waiting *many* months, we ended up writing our
own back in 1988. The needed tools: skill and OSS and about 2 or 3
months of time on the part of one of the CAD guys in my group (with
input from designers). The person who did this work was hired from
college to be a design engineer and had been temporarily assigned to
work for me in the CAD group when I joined the operation. He knew what
it meant to have a hierarchical netlister available to him when he went
on to join the design teams later as planned.
The definition of how it would work and learning curve took a little
more time, but the system was revised and generalized by another of the
CAD guys in the group to the point where adding a new true hierarchical
output for another simulator could be done about 1 or 2 weeks of
additional time to handle the new output formats. When I left some time
back, this company had working hierarchical netlisters for an
assortment of simulation programs used by the designers for over 4
years, and Cadence still had not added one to Edge or Artist when I
last looked about 10 months ago! Not everyone has migrated to Opus yet,
so that is another story.
The point of all this being that this was not an impossible task in any
way (a good college grad could do it!), and Cadence should have had a
hierarchical netlister very early on. My belief is that this was a
classic symptom of operation of large software companies that are too
busy working on the latest new-fangled bell-and-whistle feature (that
has little to do with how the system is used), and who don't listen to
their end-users at all.
>Maybe the only way for this to improve is for a Cadence software developer (not an AE
>that communication path doesn't seem to work well enough) to sit down with me for a
>couple of days and see how a circuit designer actually uses this tool.
The attitude inside Cadence among the software developers seems to be
one of "we know better than the users". I know - I offered to do what
you recommend on a number of occasions, but we would only get AE's to
come out. Having a good AE helps, and we had a very good one, but they
have *little* clout with the developers. So, what you ask for may be
unlikely, but who knows? Maybe Cadence has learned some in the last few
quarters of bad times! Give them a buzz and ask.
Z
--
-------------------------------------------------------------------------
| Syed Zaeem Hosain P. O. Box 610097 (408) 441-7021 |
| Z Consulting Group San Jose, CA 95161 s...@zcon.com |
-------------------------------------------------------------------------
Syed Zaeem Hosain
In article 11...@mlb.semi.harris.com, j...@billy.mlb.semi.harris.com (James W. Swonger) writes:
>
> The netlist is flat because SPICE2 and cdsSPICE which derives from
> SPICE2 is a flat simulator.
Spice2 may be a flat simulator internally, but its input decks can be
completely hierarchical for sure.
> You should see what facilities you have for backannotation of
> simulator device names onto your schematic. In our design system
> this is done with additional properties and code. A pencil works
> too.
I certainly hope you are jesting here! Since the schematics *are*
hierarchical, taking a flat simulator netlist and backannotating into
the schematic will lead to multiple names for device/nets in *any*
block that occurs more than once. Just how do you expect the schematic
to keep these straight?
Plus, if you work on 10 transistor circuits, then, yeah, a pencil is
handy, but any *real* design today is thousands to hundreds-of-
thousands of gates/devices - you could back-annotate the rest of your
life away on a small microprocessor with a pencil. I suppose this could
be job security of a sort, but one hell of a dull job. :-)