How to access layout object property edit form

[Suresh Jeevanandam]

Hi all,
The layout objects property edit form (that comes up when you press
"Q") is not accessible from skill. Why is it so...

Regards,
Suresh

 

[Bernd Fischer]

What about

q = leHiEditProp()
<Shift>q = leEditDesignProperties()

???

Bernd

Suresh Jeevanandam wrote:

Hi all,
The layout objects property edit form (that comes up when you press
"Q") is not accessible from skill. Why is it so...

Regards,
Suresh

 

[Suresh Jeevanandam]

Bernd,
Actually I want to access the skill form object that I can assign to a
variable etc.
For schematic property form, one can use the skill variable
schObjPropForm to access the field properties through skill.
But for the layout property form, I am not seeing any such variable.

I think my earlier message was not very clear.

Thanks for the response.

Regards,
Suresh
Bernd Fischer > wrote:

What about

q = leHiEditProp()
Shift>q = leEditDesignProperties()

???

Bernd

Suresh Jeevanandam wrote:

Hi all,
The layout objects property edit form (that comes up when you
press "Q") is not accessible from skill. Why is it so...

Regards,
Suresh

 

[Bernd Fischer]

I would have suggested
hiGetCurrentForm()
but I realized that it doesn't work either
for the Layout edit prop forms.

Bernd

Suresh Jeevanandam wrote:

Bernd,
Actually I want to access the skill form object that I can assign to
a variable etc.
For schematic property form, one can use the skill variable
schObjPropForm to access the field properties through skill.
But for the layout property form, I am not seeing any such variable.

I think my earlier message was not very clear.

Thanks for the response.

Regards,
Suresh
Bernd Fischer > wrote:

What about

q = leHiEditProp()
Shift>q = leEditDesignProperties()

???

Bernd

Suresh Jeevanandam wrote:

Hi all,
The layout objects property edit form (that comes up when you
press "Q") is not accessible from skill. Why is it so...

Regards,
Suresh

 

[S. Badel]

1) Say the user has thousands of instances of standard pdk cells. And
say he wants to change a particular parameter. If he changes the
parameter through the property form, all the callbacks are called, and
no problem. Since the number of instances is really huge, whats the
recommended way to change the parameters. Note that these pcells are
defined using cdf. [ The CDF mechanism itself is very difficult to
understand for me ]
Through the UI, you can do a search, then select all, then properties, check

common and change the parameter. Supposing you want to change all to the same
value, of course.

As to how modify a parameter with SKILL, while still calling the CDF callback,
good question. I have found the function cdfExecParamCallback which doesn't
seem to be documented. Otherwise, it is possible to set cdfgData to the CDF
of your cell, and call axplicitely the callback using evalstring.

2) Changing the pin names. There is no straightforward way to accomplish
this in the PI. However it is very simple in HI, just press Q go to the
connectivity section, edit the value, press OK.
I do not see what's so hard in changing pin names with SKILL. maybe you're mixing up

pins and terminals.

cheers,

stéphane

 

[Suresh Jeevanandam]

S. Badel wrote:

Through the UI, you can do a search, then select all, then properties,
check
common and change the parameter. Supposing you want to change all to the
same
value, of course.
I want to change the parameter values based on their current value ( for

example scaling cap values by some amount). So, Clicking the "common"
button and changing the value does not work for me.:-(

As to how modify a parameter with SKILL, while still calling the CDF
callback,
good question. I have found the function cdfExecParamCallback which doesn't
seem to be documented. Otherwise, it is possible to set cdfgData to the CDF
of your cell, and call axplicitely the callback using evalstring.

I do not see what's so hard in changing pin names with SKILL. maybe
you're mixing up
pins and terminals.
I am trying to change the pin name of a pin that is created using the

menu command *create->pin*. In PI I could not see any solution other
than deleting the shape and the associated net and then recreating the
shape and net(with new name) and attaching them.

Thanks for the response.
--
Suresh

 

[Andrew Beckett]

On Wed, 02 Mar 2005 13:32:56 +0100, "S. Badel"
<stephane.badel@REMOVETHISepfl.ch> wrote:

then comes the problem of calling the callback. maybe Andrew can help on this,
but my nasty solution is
cdfgData = cdf
evalstring( cdfParam~>callback )

See solution 11018344 on sourcelink.

Sorry for the quick answer - I'm rather busy at the moment.

Andrew.

 

[Andrew Beckett]

On Thu, 03 Mar 2005 17:50:21 +0530, Suresh Jeevanandam
<sureshj@DELETETHISti.com> wrote:

Andrew thanks for the info.

My humble opinion is that more thought could have been put when the cdf
mechanism was defined.

I am finding it very very difficult to understand the cdf related stuffs.

The API should have been defined in such a way that when the user does,
dbFindProp(inst propName)->value = newValue
the system should find whether the inst has any cdf mechanism and call
the callbacks accordingly.

(If skill has some limitations in overloading the set() function, then a
separate function should have been written which sets pcell parameters,
something like,
pcSetParam(inst propName value)
)

Such a system would help not only the cadence users but also cadence
developers them self.

Regards,
Suresh

The trouble is that this was designed something like 14-15 years ago, without
the benefit of seeing how everyone would use CDF callbacks. It was clearly
envisaged as allowing form field callbacks rather than parameter change
callbacks.

There's no reason why parameter change callbacks could not have been
implemented - but there's still a difference. With CDF callbacks, the
callbacks would need to be triggered when a parameter changes on the form -
which is before the changes are actually applied to the database. The system
would need to be able to support both somehow, which is not that
straightforward.

So it's not as easy as it seems...

Even if this were done at the DB level, there are still no end of troubles
that callbacks cause in a system that supports parameter inheritance. See
posts passim where I've talked about the problems with callbacks:

http://groups.google.co.uk/groups?q=andrewb+callback&hl=en&lr=&group=comp.cad.cadence&selm=3udogvsrap01un1t825u5tv8sva0lcu3l0%404ax.com&rnum=1

Andrew.

 

[Andrew Beckett]

The form is not a SKILL form, but implemented natively in Motif.

So you can't mess with it using SKILL. Why do you want to? There
may be other ways of doing what you want to do if I know the end goal.

Andrew.

On Tue, 01 Mar 2005 14:30:41 +0100, Bernd Fischer
<""bernd.fischer\"@xignal-A%&HY%$v#&G=.de"> wrote:

I would have suggested
hiGetCurrentForm()
but I realized that it doesn't work either
for the Layout edit prop forms.

Bernd

Suresh Jeevanandam wrote:
Bernd,
Actually I want to access the skill form object that I can assign to
a variable etc.
For schematic property form, one can use the skill variable
schObjPropForm to access the field properties through skill.
But for the layout property form, I am not seeing any such variable.

I think my earlier message was not very clear.

Thanks for the response.

Regards,
Suresh
Bernd Fischer > wrote:

What about

q = leHiEditProp()
Shift>q = leEditDesignProperties()

???

Bernd

Suresh Jeevanandam wrote:

Hi all,
The layout objects property edit form (that comes up when you
press "Q") is not accessible from skill. Why is it so...

Regards,
Suresh

 

[Suresh Jeevanandam]

Andrew,
I find two places where this could be extremly helpfull.

1) Say the user has thousands of instances of standard pdk cells. And
say he wants to change a particular parameter. If he changes the
parameter through the property form, all the callbacks are called, and
no problem. Since the number of instances is really huge, whats the
recommended way to change the parameters. Note that these pcells are
defined using cdf. [ The CDF mechanism itself is very difficult to
understand for me ]

2) Changing the pin names. There is no straightforward way to accomplish
this in the PI. However it is very simple in HI, just press Q go to the
connectivity section, edit the value, press OK.

If we can access the form structure through skill, I can mimic the
entire HI events in a loop.

Regards,
Suresh


Andrew Beckett wrote:

The form is not a SKILL form, but implemented natively in Motif.

So you can't mess with it using SKILL. Why do you want to? There
may be other ways of doing what you want to do if I know the end goal.

Andrew.

On Tue, 01 Mar 2005 14:30:41 +0100, Bernd Fischer
""bernd.fischer\"@xignal-A%&HY%$v#&G=.de"> wrote:


I would have suggested
hiGetCurrentForm()
but I realized that it doesn't work either
for the Layout edit prop forms.

Bernd

Suresh Jeevanandam wrote:

Bernd,
Actually I want to access the skill form object that I can assign to
a variable etc.
For schematic property form, one can use the skill variable
schObjPropForm to access the field properties through skill.
But for the layout property form, I am not seeing any such variable.

I think my earlier message was not very clear.

Thanks for the response.

Regards,
Suresh
Bernd Fischer > wrote:


What about

q = leHiEditProp()
Shift>q = leEditDesignProperties()

???

Bernd

Suresh Jeevanandam wrote:


Hi all,
The layout objects property edit form (that comes up when you
press "Q") is not accessible from skill. Why is it so...

Regards,
Suresh

 

[S. Badel]

Suresh Jeevanandam wrote:

I want to change the parameter values based on their current value ( for
example scaling cap values by some amount). So, Clicking the "common"
button and changing the value does not work for me.:-(
Well, in that case the second part of the answer is relevant.

More explicitely, given you have an instance inst with property prop that
you want to change, you can do :

cdfData = cdfGetInstCDF(inst)
cdfParam = cdfFindParamByName(cdf "prop")
oldval = cdfParam~>value
cdfParam~>value = f( oldval )

then comes the problem of calling the callback. maybe Andrew can help on this,
but my nasty solution is
cdfgData = cdf
evalstring( cdfParam~>callback )

I am trying to change the pin name of a pin that is created using the
menu command *create->pin*. In PI I could not see any solution other
than deleting the shape and the associated net and then recreating the
shape and net(with new name) and attaching them.

In any case you do not have to delete the shape. I guess the problem arises because of all
the interdependency between nets, pins, terminal names etc... One easy way is to create the
new net, then merge the old one into the new one, the rename the terminal. as for the pins,
i think their names do not matter.

pin=shape~>pin
term=pin~>term
net=term~>net

newnet=dbMakeNet( cv "FOO" )
dbMergeNet( newnet net )
term~>name="FOO"


stéphane

 

[Suresh Jeevanandam]

Andrew thanks for the info.

My humble opinion is that more thought could have been put when the cdf
mechanism was defined.

I am finding it very very difficult to understand the cdf related stuffs.

The API should have been defined in such a way that when the user does,
dbFindProp(inst propName)->value = newValue
the system should find whether the inst has any cdf mechanism and call
the callbacks accordingly.

(If skill has some limitations in overloading the set() function, then a
separate function should have been written which sets pcell parameters,
something like,
pcSetParam(inst propName value)
)

Such a system would help not only the cadence users but also cadence
developers them self.

Regards,
Suresh

Andrew Beckett wrote:

On Wed, 02 Mar 2005 13:32:56 +0100, "S. Badel"
stephane.badel@REMOVETHISepfl.ch> wrote:


then comes the problem of calling the callback. maybe Andrew can help on this,
but my nasty solution is
cdfgData = cdf
evalstring( cdfParam~>callback )


See solution 11018344 on sourcelink.

Sorry for the quick answer - I'm rather busy at the moment.

Andrew.