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 have a design with an object on a single layer with a fairly complex boundary (The object has 602 points in its outline). I am using the dbLayerSize(...) routine to size the layer and place the result in a different layer. In this instance I am resizing by 0 (so that should help eliminate resizing issue possibilities) but in other cases the amount could be anything and I am seeing the same issue with non-zero values. dbLayerSize normally works just fine but for this particular object the result is an object with diagonal gaps across it. Most of the outline is correct but the object has been divided into sections separated by four gaps of differing width with a 45° slope. Since the object is on a keepout layer the diagonal gaps are a problem. I tried the regular menu "size" command on the object and it works fine. I even tried copying the object to a different cell and running dbLayerSize with the same result.
Are there known issues like this with dbLayerSize? Is there a work-around?
None of the vertices of the object lie on top of an adjacent point. 484 are off-grid but that shouldn't matter. One thing that is very bizarre about this problem is that it doesn't just affect this object. Nearby objects on the same layer included in the LPPObjects list (see call below) which are being sized at the same time are chopped up along the same diagonals even though they are not related in any other way. That suggests that there must be some internal variables common to both objects that are getting messed up. This looks like a Cadence SKILL routine bug.
If you need it, I can provide the list of points.
The call is being made as follows: dbLayerSize(Cv LPPTo LPPObjects SizeBy)
I can't quite see why this would happen - I initially wondered whether it was an old problem where the function used to snap to grid in a range of versions (but this was fixed some time ago - see article 11481956.
Please provide the list of points, and the subversion you're using (the output of getVersion(t)).
In reply to Andrew Beckett:
In reply to thomas1000:
It does appear to be a peculiar bug which only happens if you use dbLayerSize with 0.0 as the size. It doesn't happen with -0.001 or 0.001, only with 0.0 itself. I get lots of warnings:
*WARNING* Coordinate -nan is under the min -2147483647 and -2147483647 is used
In the CIW. You could just use:
dbLayerOr(cv "Metal3" list(shape) nil)
dbLayerSize(cv "Metal3" list(shape) 0.0)
if you're trying to size by exactly zero. Yes, it fractures into a number of shapes (5 in my case) but that doesn't matter.
You could also use the leLayerSize function (unless you're hoping to do this in a pcell, because le functions are not allowed in pcells):
leLayerSize(cv list("Metal2" "drawing") 0.0 list("Metal3" "drawing"))
This will size all shapes on a particular layer and output them on another. This results in a single shape in this case.
You could also use leSizeShape - but that doesn't do anything if you have a size increase of 0.0
I also tried the dbLayerSize with 0.0 as the size in IC615, and it works fine there.
So it looks like a particular odd bug that's in IC5141 alone, and is something specific to how dbLayerSize interfaces to the underlying sizing/layer processing engine (it's ultimately the same code underneath that's used by leLayerSize and dbLayerSize, but they're called in different ways).
Yes, I was getting all of those nan warnings as well and suspected that it was being caused by dbLayerSize but had not definitely pinned that down.
Thanks for your quick response on this - I feel a lot better knowing that there is a solution. I am not creating a PCell in this case. If I were I would just write my own size routine but, having done it before, they are not as easy to write as you would think on the surface.
Although if you were creating a pcell, you could just use dbLayerOr or even dbCopyFig to copy across to the new layer. It's only an issue if the size is 0.0 (so in other words you're not actually sizing it) - any other size seems fine. So there would be no need to write your own sizing algorithm even then.