Using dbTransformBBox

 Hu Kasyab

 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.

Ted

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.

Derek

Hi Ted,

Thanks for the pointers. They work with the minor correction that dbLayerSize also needs the layer name on which to output the new shapes.

So  

newShapeList = dbLayerSize( cv_lay list(car(OD_shape_list)) .05)

becomes

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?

Thanks again 

Kasyab 

Hi Derek,

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.

 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.

Regards,

Andrew.

 Hi Derek

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.

Ted

 Ted,Derek, Andrew,

  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.

 Kasyab

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.

Derek

 Hi Derek

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.

Ted

kasyab said:

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.

Kasyab,

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).

As for user units and database units. Typically for layout, the user units are defined to be "micron", and then the database units defined as a certain number of database units per user unit (DBUPerUU). Typical values of DBUPerUU are 1000 or 2000. The actual database is stored as integer coordinates, and so with a DBUperUU of 1000, each integer value in the database corresponds to a nanometre. However, pretty much every command or function is in terms of user units (i.e. microns).

You can check these units for a cellView, by doing:

cvId=geGetEditCellView()
cvId~>userUnits
cvId~>DBUPerUU

The defaults are set in the technology file - search for viewTypeUnits in cdnshelp.

Regards,

Andrew.