How to access layout object property edit form

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

 

What about

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

???

Bernd

 

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,

 

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

Bernd

 

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.

 

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

 

1) Say the user has thousands of instances of standard pdk cells. And

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.

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

 

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

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.

 

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 )

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

 

See solution 11018344 on sourcelink.

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

Andrew.

 

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?&rnum=1

Andrew.