I failed to search the manual and the forum to find a way to copy and rotate a shape I created with any agle like 15, 30, 45 etc.
I noticed some posts said that rotate with any angle may raise lithography issues. But in MEMS application, it's very popular to use all kinds of "strange" shapes. As the line/space is over 1um, the litho problem can be neglected. Then, what can I do in skill code?
Not sure of your application but have you tried
dbCopyFig( d_fig d_cellView [ l_transform ] )
Use the transform option to rotate the object. '((0 0) "R90" 1.0) would rotate the object 90 degrees.
In reply to psill000:
In reply to richardyuan:
There's dbTransformCellView which will transform everything in a cellView by the specified magnification and angle. Note that this cannot transform objects which are constrained to only be at 90 degree multiples (such as instances), so you should normally do this on flat layout.
So if you want to transform selected shapes, what you could do is write a function which moves them (using dbMoveFig) to a temporary cellView, does a dbTransformCellView() and then moves them back to the original cellView.
This is probably easier than trying to write your own code to transform every kind of shape by arbitrary angles. There's leHiRotate, but this is an "hi" function and doesn't have a procedural equivalent.
Hi Richard, Andrew,
Ha; I did not know dbTransformCellView could do that! Andrew is right, of course; that is indeed the easiest solution—provided that function is available in your version of Virtuoso.
I had started writing a small solution; I’ll append it here in case it helps. It basically implements arbitrary affine transformations on points, plus a small dbCopyFig-like helper function:
matrix = VedaGeomAffineMakeIdentity()
matrix = VedaGeomAffineScale(matrix 2.0 0.5)
matrix = VedaGeomAffineRotate(matrix 30*degrees)
VedaGeomAffineCopyFig(fig cv matrix)
I’ve included a tiny demo in the source tree; it draws some shapes on the y* layers of a given cell view:
You can find the code (full of TODOs) here (Git repository, snapshot):
The license is MIT/Expat. Let me know if you need more info… or have some patches :)
In reply to ztzg:
Thank you for your help. As a beginner and not dedicate to layout, it seems hard for me to ultilize your code.
I'll try it when I have time.
In reply to Andrew Beckett:
I tried your solution. It seems have precision issues.
When the rotation angle can divide 360 exactly, like 20,30,60 etc., It looks great.
But when I try to place 19 semilar shapes along a circular edge with same interval, it doesn't work well.
I'm guessing that you're rotating each shape incrementally, which would mean you accumulate rounding errors. You didn't share your code, so that's purely a guess.
I wrote the following:
procedure(CCFcreateRotatedShape(cv layerName angle inner outer width) let((tempCv) tempCv=dbOpenCellViewByType(cv~>libName cv~>cellName "scratch" "maskLayout" "w") dbCreateRect(tempCv layerName list(inner:-width/2.0 outer:width/2.0)) dbTransformCellView(tempCv 1.0 angle) foreach(shape tempCv~>shapes dbCopyFig(shape cv list(0:0 "R0" 1)) ) dbClose(tempCv) t ))procedure(CCFrotateExample(@key (cv geGetEditCellView()) (spines 20) (inner 25) (outer 45) (width 4) (layer1 "Metal3") (layer2 "Metal2")) let((radius) radius=(inner+outer)/2.0 dbCreateEllipse(cv layer1 list(-radius:-radius radius:radius)) for(i 0 sub1(spines) CCFcreateRotatedShape(cv layer2 i*360.0/spines inner outer width) ) ))
And then ran (using gpdk090):
CCFrotateExample(?spines 19 ?layer1 "Via2" ?layer2 "Via5")
(purely to get some pretty colours). As you can see, this looks pretty evenly spaced and the shapes look regular:
The setup has 2000 DBUPerUU so has a good level of resolution - I don't know what your database resolution is compared with the size of your structure.
Your code has two sources of rounding errors.
The first is that you compute the angle as 360/SETS. Since SETS is an integer, and 360 is a literal integer, this is an integer division. So if SETS is 19, this ends up with an angle of 18 rather than 18.94. If you change the expression to 360.0/SETS then this will eliminate this source of rounding error.
The second (much smaller) source is that each time it does a transform cellview, copies the figure and then transforms again. At each transform there will be a small rounding error of each point in the transformed shape to snap it to the database units used because of the resolution of the database. Because you are doing a series of transformations, each starting from the result of the previous transformation, these small errors will accumulate. They may be small enough that you can ignore, but the approach I showed was to transform from the original shape each time and vary the angle each time (so the first rotates by angle, second by 2*angle and so on) and so the small rounding errors would not accumulate.
Oh, what a stupid mistake I've made. Integer divided by integer gets an integer, the skill rule...
That really helps. Thank you andrew.