Suggestion to saving states in analog artist

[Svenn Are Bjerkem]

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,
--
Svenn

[fogh]

Hi Svenn,
The most effective solution would be when the ^hi field creation functions
would always initialise with the last value (from current session, otherwise
from a dot file). There are many such forms in dfII with frustratingly empty
fields that could better be drop-down with a choice of valid defaults and
previous values.

As you mentionned, you could play around with the CsevMainFormFieldSets that I
posted before (topic: analog artist resize ). Don t be afraid to experiment: it
is all very plain code. All you need is in just 2 manuals: the skill user
interface man (chapter on forms), and the artist manual (to get info on the
session, like path to states).

Sorry I have no time for this. Some thing$ take priority. That s how I also
left unfinished that toolbar with symbols from the PDK - for the time being.



Svenn Are Bjerkem wrote:

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.

[Svenn Are Bjerkem]

fogh wrote:

Sorry I have no time for this. Some thing$ take priority. That s how I
also left unfinished that toolbar with symbols from the PDK - for the
time being.

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

[Andrew Beckett]

On Fri, 18 Feb 2005 07:26:29 +0100, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

fogh wrote:
Sorry I have no time for this. Some thing$ take priority. That s how I
also left unfinished that toolbar with symbols from the PDK - for the
time being.

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.

[fogh]

Andrew Beckett wrote:

On Fri, 18 Feb 2005 07:26:29 +0100, Svenn Are Bjerkem <svenn.are@bjerkem.de
wrote:


fogh wrote:

Sorry I have no time for this. Some thing$ take priority. That s how I
also left unfinished that toolbar with symbols from the PDK - for the
time being.

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

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.

[adsfadsf]

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

[Svenn Are Bjerkem]

adsfadsf wrote:

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.

--
Svenn

[G Vandevalk]

To add

Many users wish to save their artist_states.

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

--
--
Gerry Vandevalk vdvalk@rogers.com
IC Tooling Ltd. www.ictooling.com


"Svenn Are Bjerkem" <svenn.are@bjerkem.de> wrote in message
news:cvc219$6dc$1@athen03.muc.infineon.com...

adsfadsf wrote:
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.

--
Svenn

[Svenn Are Bjerkem]

G Vandevalk wrote:

Many users wish to save their artist_states.

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?

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

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.

--
Svenn

[G Vandevalk]

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

"Svenn Are Bjerkem" <svenn.bjerkem@infineon.com> wrote in message
news:cvekn6$2b1$1@athen03.muc.infineon.com...

G Vandevalk wrote:

Many users wish to save their artist_states.

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?


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

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.

--
Svenn

[Svenn Are Bjerkem]

G Vandevalk wrote:

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

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.

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.

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

[Erik Wanta]

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

[Erik Wanta]

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

[Andrew Beckett]

On 23 Feb 2005 20:01:49 -0800, "Erik Wanta" <erikwanta@starband.net> wrote:

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

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.

[Svenn Are Bjerkem]

Andrew Beckett wrote:

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.

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

--
Svenn