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