Suggestion to saving states in analog artist

Hi,

I have a problem regarding saving of states in Analog Artist: I cannot
remember which state I opened, and analog artist always suggest "state1"
as save name.

Let me describe the problem a bit more:
I have a testbench schematic with sources that is static because I use
variables to set the different values. Each simulation get a descriptive
state name like: TRAN_power_up, TRAN_vdd_noise, AC_gain, XF, DC_sweep
and so on. If I want to do something else, then I just change state.
Problem is when I change something I would like to save it back to the
proper state. As I have many transient simulations it is not easy to
deduct what the save name is from the analysis setup page, and when I
want to save, the "save as" dialog *always* suggest state1.

How this could be improved:

Suggestion one: When initializing the "save as" dialog, suggest the name
of the state that was loaded last. There is an overwrite confirm dialog
already implemented.

Suggestion two: In the analog artist control window, there is a frame
where library, cell and view is listed. Here it would be possible to
insert a fourth line with state name. Then saving of a state would be a
question of selecting the proper state from the "save as" list box.

Suggestion three: Implement suggestion one *and* two.

Is it possible to do this from .cdsinit?
Some of the more SKILLed people here have written routines that
manipulate the analog artist window to resize the contents. I know from
tcl/tk aware applications that it is possible to manipulate the gui
layout from the internal command line. Now what I need is a way to
attach a callback to the "load state" menu item that remember the save
state name, and a callback to the "save state" menu item that replace
"state1" with the name stored by the "load state" callback.

Or, I need to know the widget path to the frame that contains the
library, cell, view info so that I can create and insert a label which
change dynamically with the state that I load.

Unfortunately, the information that I need is scattered over many
manuals, and I have a) no clue where to start and b) this is a task over
my unSKILLed head, so I plea for some advice.

Kind regards,

 

Thank you very much, but I didn't mean that you should do the work for
me. Thanks for the startup help. If I get problems I will surely come
back to this thread.

 

Svenn,

I'd sooner you log this with us as a service request - that way either:

a) it's an existing enhancement request (I've not checked) and your request
will add more weight
b) it's a new enhancement request - and it should get into the system.

I think these are good ideas, and I'd sooner they get done centrally rather
than trying to hack them in (which will be far from trivial, especially
without using private functions).

Regards,

Andrew.

 

Indeed. I wanted to put in my answer to Svenn that it is best to file a
PCR, and I did it to quick and forgot.

 

See previous post titled:
saving custom data into artist states?

Please request this functionality also so that you can share states
with others that you named correctly.

 

I need some additional information on this, Erik. What do you mean by
'others'; other engineers, other cells? States are normally saved in
..artist_states (why on earth is such an important directory dotted
invisible?) and is basically reachable by all. If you meant something
else, I need more info.

 

To add

Many users wish to save their artist_states.

I often save them into users libraries (or same level as libraries)

 

It makes sense to me that users want to save their states. Do you mean that
they want to have a separate artist_state directory all by themselves?

Sorry but I don't understand, because in my environment states are always
saved under the name of a library. Are you moving the directories by
commands in the unix shell?

If you look at the save directory .artist_states, there is a four level
directory structure underneath: 1. level has the same name as the library,
2. level has the same name as the cellName. 3. level is the name of the
simulator, 4. level is the name of the state. Then comes the files with the
gory lisp code.

I think it is important to have the save states behavior modified in such a
manner that it actually is a help to the user. The way it is now, it
_always_ suggest "state1" as save name, regardless if it is the first time
you save the state, or if you have loaded one that you have modified and
want to save it back. I have so often overwritten wrong states and lost
work because I have forgotten which one I am currently using. I remember
back to the days when it even didn't list the names of the states already
existing.

 

What I have done for users is simply change the location where the
..artist_states are saved.

Instead of storing them in ~/.artist_states many users want their
states saved in ~/PROJECTS/<name_of_project>/artist_states

Then when they invoke artist for this project, I have this stored in a local
startup
variable. (RTM on this, it is a standard configuration variable)

This lets them switch and have sets of artist_states directories.

( I would never mess with the internal file names ... )

-- gerry

 

That's what we do here, too. Design support has created a design
environment in perl that sets up all the project related stuff and then,
when the designer calls icfb, remaps the $HOME variable so that the user
"magically" has a new home in the project where he works. This is not
cadence stuff so different companies do this differently. In my previous
job I had many projects, and sometimes missed the possiblilty to copy
states across projects. As I was doing more verification than design,
the states saved were system related and each asic had to work in the
same system. Now I have totally different focus, and my needs are also
different.

But you can only have one active at the time, and you have no indication
from ADE which one you are using...

If we take an improvement of the save states one step further, then it
would be nice to also have the possibility to choose .artist_states
location. This could be a dialog just like the model library chooser
where the user can have many locations listed, but one active at a time.
The current location should be visible in the save states dialog so that
the user can clearly see:
- Which state he is currently working with.
- Where is this state currently saved. (location of .artist_states)
- Has he done any modifications to the state (is the current state
modified during the session)
- In some rare cases it would be nice to save a state back to a
different library and cellname than is currently active.

I really think that the concept of states could be enhanced with a state
editor where it would be possible to modify and manipulate states in a
separate application. Sometimes you want to change the parameters of a
bunch of states at once, specially when signal names of saved signals
change, or the transient simulations have to be changed. If one also use
a lot of definition files and stimuli files that should be consistent
across the simulated states such a one-stop application would be nice.
But this is outside of the original context and could probably be coded
quicker in, let's say, Tcl/Tk.

Well, I soon have to write that PCR to cadence, and if somebody has
opinions on save states, then hurry up.

Kind regards,

 

Svenn:
Saving states as cell views is very clean.
See previous post titled:
saving custom data into artist states?

 

Svenn:
The states are critical to repeatability. If the state is saved as a
cell view then it gets copied when the test bench is copied. It can
also be data managed and shared with other engineers all over the
world. If the states are saved as cell views and then copied to
~/.artist_states prior to loading then it is fully backward compatible
with the current states approach. That is, it would be very easy for
Cadence to just add a .cdsenv variable to enable the saving of states
as cell views and just add a pretrigger to copy the states from the
cell view to the ~/.artist_states directory before bringing up the load
form and add a posttrigger to copy the states from ~/.artist_states to
a cell view when they are saved instead of creating a whole new state
mechanism.

I think the parametric, optimization, and assura states should be saved
as cell views also.

 

There is a plan to do this properly (not just do this trigger idea) in an
upcoming release. Not sure about assura states, but the ADE-related states
would be unified and have both a cellView and directory-based model.

Andrew.

 

Do I understand you correctly if I assume that Cadence is working on a
more user friendly dialog to save states?

 

Read you loud and clearly now. I wasn't thinking in this direction so I
had a slight problem with understanding.

I am just a little afraid that the cellview listing in the library
manager is going to be filled up beyond practicallity.

 

Yes, and the ability to save states as cellViews. Also, to unify the multiple
state mechanisms within ADE.

Andrew.

 

Andrew,
how many such deliciously good news like this are still in your sleeve ?
Can you anounce those relating to ADE in the c.c.c ?

 

Well, that would be saying...
Actually I need to be careful about some of these, since if they're a way off,
plans have a habit of changing - it's always dangerous announcing things too
early (certainly if it is before I've seen it in action).

Andrew.

 

And sometimes the plans that look great on paper just don't work out so
well when implemented. Plans and prototypes show how something can
work; the actual product has to work (the stuff that's easy and fun to
implement) *and* not break (difficult and tedious).

Not that this is the case here with ADE. Just something to be wary of
in general, whether it's computers, cars, houses, medical equipment, or
EDA software.

Dave

 

OK. I will be patient. Simply knowing that there are intentions to
improve ADE is enough to boost my morale already.