Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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.