Stats

  • Locked Locked
  • Replies 5
  • Subscribers 143
  • Views 2533
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

dbLayerSize seems to be faulty - is there a work-around?

thomas1000

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)

Parents

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

    rather than:

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

    Regards,

    Andrew.

Reply

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

    rather than:

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

    Regards,

    Andrew.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.