I am a relatively new user of SKILL. My problem is with the use of dBTransformBBox function. I am able to apply this function to scale the size of objects which are uniquely represented in bounding box fashion("rect" objects). My question is if this function is applicable to polygons as well.
Specifically when I apply dBTransformBBox to a shape in the active layer there is no scaling. As far as I can tell these shapes differ only in that they are represented as "polygon" objects in terms of their geometry. dBTransformCellView scales all layers in a cell view, so it should be possible to scale polygons as well. I tried to use the dbLayerSize function to achieve scaling on the active layer but I do not understand the results returned by it.cvID~>DBUPerUU returns 1000.0.I am attaching a couple of pictures that show the layout before and after the application of dbLayerSize and also some example code of what I used to achieve this.
cv_lay = dbOpenCellViewByType("SEMIREG_STM040" "SR_FA" "layout" "" "a")
shape_list = cv_lay~>shapes
OD_shape_list = nil foreach(shape shape_list if(shape~>lpp == list("OD" "drawing") then OD_shape_list = append1(OD_shape_list shape) );if );for
dbLayerSize(cv_lay "OD" list(OD1) 0.50)
dbLayerSize(cv_lay "OD" list(OD1) -0.50) [returns nil]
leLayerSize(cv_lay list("OD" "drawing") -0.50 list("OD" "drawing")) [also returns nil]
leLayerSize(cv_lay list("OD" "drawing") -0.50 list("OD" "drawing"))
I looked at other posts referring to leLayerSize (which I see in the manual is a layout editor procedural version of the dbLayerSize function), but the problem of the sizing value is still present here. There is no hierarchy in my layout.
I also tried leSizeShape for the specific shape I extract above.
SYNTAX ERROR found at line 5363 column 16 of file *ciwInPort*
*Error* lineread/read: syntax error encountered in input
Any help will be appreciated.
original cell view
cellview after applying dbLayerSize with 0.5 sizing
cellview after applying leLayerSize with 0.5 sizing
leSizeShape is no longer a valid command so you probably should not use it.
Several comments about your code:
You are sorting all the shapes to find the ones on OD1. This can be lengthy as there may be many shapes in the database. It is much faster to sort the cellView~>lpps instead and then get the shapes:
lpp = car(setof( lpp cv_lay~>lpps lpp~>layerName == "OD" && lpp~>purpose == "drawing" ))
OD_shape_list = lpp~>shapes
dbLayerSize operates on the shapes in the argument, creating new shapes and returning their ID's. The original shapes are not touched. If you size a shape such that it has no area, the shape is deleted.
newShapeList = dbLayerSize( cv_lay list(car(OD_shape_list)) .05)
anotherNewShapeList = dbLayerSize( cv_lay newShapeList -.05 )
You will have to delete all the intermediate shapes.
Several additonal comments:
1. Speaking of performance, you should use "cons" instead of append1 since this does not appear to be an order dependent list. With lots of shapes in a design, cons will significantly improve your performance over append1.
2. Cadence provides dbTransformBBox (Ted reminded me of this the other day) and dbTransformPoint. If you need to transform a list of points like in a polygon, you'll either need a foreach loop, or a mapcar like this:transformedPoints = mapcar('(lambda (x) dbTransformPoint(x transform)) shpId~>points)
3. Your syntax error looks like you typed a zero instead of the letter O. O0 <- Notice the zero is skinnier.
In reply to theopaone:
Thanks for the pointers. They work with the minor correction that dbLayerSize also needs the layer name on which to output the new shapes.
newShapeList = dbLayerSize( cv_lay "OD" list(car(OD_shape_list)) .05)
What is confusing for me is what is meant by user units for the scale value? Also how are the user units different from DBU's?
In reply to dmay:
I just typed that up quickly and used the first function that came to mind and not be ing well versed with SKILL, it wasn't the best. That said, your point is well taken since performance will be an issue for me since I have to run these transformations on about 200 cells.
Your comment about dbTransformBBox is interesting though. Logically speaking that would work the best for me since it works on the entire shape and the shape list can be processed using a foreach loop as you mention (I haven't used mapCar before ), but I haven't got it to work and that seemed strange to me. I'm not certain where I'm going wrong with this though.
In reply to kasyab:
If you have a polygon, then using newBBox=dbTransformBBox(polygon~>bBox transform) is not going to be terribly helpful, because you can't set polygon~>bBox - you can only set the points to update it - the bBox is a derived attribute.
If you want to "scale" rather than "size" an object, your simplest solution would be to use dbMoveFig(polygon polygon~>cellView list(0:0 "R0" scaleFactor)) - this will cope with polygons, paths, rectangles, etc.
In IC615 there is a new function called mapinto. It is not the same as the other map operators in that it processes a list and maps the data into an existing list, possibly even into itself. I useit for transforming lists of points or snapping points to grid without using extra memory:
mapinto( pointList lambda ((pt) dbTransformPoint( pt transform)) pointList )
This transforms the points and puts them back into the same list. Saves on garbage collection.
Thank you all for your inputs. In the end what worked best for me was Andrew's solution since I needed "scaling" and not "sizing". I am still confused about how sizing occurs and would like to understand it better. Could you tell me where to look for detailed documentation on sizing? More to the point I think a lot of my doubts would be cleared up if I can understand the user units and how it is related to the database.
Thanks again to all of you.
Thanks for the tip Ted. I'm always looking for ways to reduce gc. We still have some 5.1.41 parts, so I'll have to use it conditionally.
You could create a mapinto macro which would have the same footprint in releases that it does not exist. It would not save GC but you would only have one code stream. I haven't checked the syntax, may have too many parentheses (don't have immediate access to Virtuoso ) but it would go something like this:
unless( isCallable( ' mapinto )
defmacro( mapinto ( var1 function var2 ) `( ,var1 = mapcar( ,function ,var2 ) ) )
You could then use mapinto for any version.
kasyabCould you tell me where to look for detailed documentation on sizing? More to the point I think a lot of my doubts would be cleared up if I can understand the user units and how it is related to the database.
In cdnshelp, search for "Sizing Objects" - you'll find some documentation related to the interactive size command which shows what it does with a picture. Essentially, if you size by 1, it will grow the shape so that each edge moves outwards by 1 unit (typically 1um).
You can check these units for a cellView, by doing:
The defaults are set in the technology file - search for viewTypeUnits in cdnshelp.
In reply to Andrew Beckett:
Thanks Andrew. Your tips helped a lot. I have some issues with my machine right now and haven't been able to check out these commands, but I deinitely will when I have the chance.