ROD: Handles PROBLEM "relative" OR "absolute" stretch?

Hi Everyone,

I am involved in Pcell design using ROD. for some superconductor
ciruits where I am supposed to make a pcell for an inductor which has
"S" shape (as shown) and requires to have 6 handles(at corners and
ends)to stretch each of these points in X or Y direction:

H2----------H1
-
-
-
-
H3----------H4
-
-
-
-
H6----------H5


where "H" are all the handles to stretch those points in X or Y
direction(so all the segment lengths can vary)

Now, I cannot use "absolute" handles , as they would not work well
after I Move->Rotate/Move->Sideways

So I tried to use "relative" handles. Now when I tried to stretch
horizontally I found that the 3 handles to the RIGHT(H1,H4,H5) of the
Pcell work well, but the 3 handles to the LEFT(H2,H3,H6) don't!?

I learn't that this is because, in "relative" stretch increase is
measured from center of Pcell. Hence when handles H1,H4 or H5 are
moved to the right , distance of these handles from center of pcell
increases and so the respective points move to the right. thats as
desired

On the other hand when handles H2,H3 or H6 are moved to the right ,
distance of these handles from center of pcell decreases and so the
respective points move to the left, thats not desired!

I will be really grateful to anyone who can help me in this respect?

Thank You
Vikram,
ps: please give a message if you think you could help but didn't
understand the problem clearly

 

Vikram,

I don't entirely understand what you're doing, but it probably depends on
whether you are using ?moveOrigin or not.

In this simple pcell:

pcDefinePCell(
list(ddGetObj("master") "mypcell" "layout")
( (width 10.0) )
let((rect)
rect=rodCreateRect(
?cvId pcCellView
?layer "metal1"
?width width
?length 10.0
;?origin -width/2:-5.0
)
rodAssignHandleToParameter(
?parameter 'width
?rodObj rect
?handleName '(centerLeft centerRight)
?stretchDir 'x
?stretchType 'relative
?moveOrigin t
;?moveOrigin nil
)
)
)

It behaves "correctly". The handles on each side either increase or
decrease the size of the metal, depending on whether they
are moved away or towards the centre of the pcell. The edges
move accordingly as well. I have moveOrigin set to t,
because the origin is in the lower left. If however I
change the origin to be the centre of the rectangle, then
I don't want moveOrigin to be t (uncomment the ?origin line,
and change moveOrigin to nil).

This is fairly well documented.

Note, I tried this in 5.0.32.500.6 (or something like that), but
I don't think this behaviour has changed for some time.

Regards,

Andrew.

 

Thank You Andrew

?moveOrigin looks good only if I assign 2 handles to the same
parameter

The pcell I'm working on has different parameters for all handles.
Suppose all handles H1,H2.... have co-ordinates (x1:y1)
(x2:y2)....respectively, then each handle controls the respective x
and y co-ordinate.(since what was desired was an inductor-pcell having
4 "turns" and having any possible shape)

H2----------H1
-
-
-
-
H3----------H4
-
-
-
-
H6----------H5

In this case I found 2 ways to go about, but am still unclear....

a) Is it possible to use the "?userFunction" in the
rodAssignHandleToParameter function to negate the "SPCInfo->increment"
so that the direction in which pcell stretches becomes opposite and
coincides with the direction in which handle is moved?


b) Is it possible to call any function (from the pcell code )which
returns the "dbId" of any selected instance(of this particular Pcell)
in the current window.(so that its transform properties can be
accessed through "rodGetObj~>transform")
This way ,if I get the "rotation" information of the instance,I
can change the co-ordinates accordingly in the pcell code, and then
use "absolute" handles.

In other words, can the "rotation" (which can be seen in the Attribute
Form of the pcell Instance) be connected to the pcell parameters in
some way.
This too can solve my problem.

A DIFFERENT DOUBT:
Can this "pcellEvalFailure" message which appears in some (illegal)
stretch positions (and ruins the CIW ) , be bypassed in some automatic
way and replaced by some other sophisticated error message. These
stretch positions are anyway undesired so they could be automatically
made unallowed.
Otherwise, unlike for simple pcells, the above pcell will too many
conditions to take into account in the code, to avoid this
"pcellEvalFailure" message

thank you
vikram