Stats

  • Locked Locked
  • Replies 5
  • Subscribers 144
  • Views 15259
  • 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

OverUnder on large polygons

lkphoto
Hi Andrew,

I have problems in performing the “OverUnder” operation (=first using dbLayerSize with a positive amount, then with a twice the same negative amount, then with the positive amount again) caused by the fact that polygons cannot have more than 4000 points in SKILL. The purpose of the OverUnder operation is to remove acute angles, too small minimum spacings, and too small features during data preparation. These would create DRC errors.

I am designing photonic components, therefore the typical size of my cells is 10um x 10um or larger, moreover I have to use orthogonal polygons, and the curves are snapped to a 1nm grid.

I have a routine that writes such large polygons as a sum of subpolygons, each having less than 4000 points.

When I apply the dbLayerSize function to all the subpolygons at the same time, Cadence crashes –I assume because all the subpolygons together have more than 4000 points.

I ended up therefore by applying the dbLayerSize operation to single pairs of neighboring subpolygon, one at the time. The problem is that the result of the OverUnder operation depends on the way the big original shape is split into subpolygons. This is clearly not a clean solution, and I discarded it. Also, it is quite slow (taking few minutes for a single layer).

As a second attempt, I tiled the big polygon (=union of the many subpolygons) using square tiles (I used to this end the dbLayerAndNot) and applied OverUnder to each of them separately. Once this was done, I repeated the operation with the dual square lattice obtained by translating the tiles by half the tile pitch in both x and y directions. The result is predictable (as far as the tile size is sufficient), but the algorithm is extremely slow because of the dbLayerAndNot operation.

I wonder if there is a known solution to this problem.

For example, is there a way to get rid of the 4000 vertices per polygon limitation?

It would be great if I handn’t to go outside the Skill environment (e.g. by using Calibre), since these pCells see a number of other post-processing steps in Skill.

Thanks a lot in advance,
Parents

  • A few points:

    • Tom is right - this is not an "Ask Andrew" forum - there are others who respond in this forum, and that's really the point - it's a community forum. I reply to these posts when I have a moment (it's not part of my job). Sure I probably respond more than most, but others do too.
    • That said, please don't send me private messages asking for responses for things that can equally well be asked in the forums or to customer support. Given that I do have a full time job here in Europe, I don't really have the bandwidth to deal with direct unsolicited private emails or personal messages (obviously I make exceptions, but it's not a scalable solution for every CIC engineer in the world to send me direct questions - this is why we have customer support).
    • You didn't mention which version you are using. There are some limitations:
      • CDB (the IC5141 and before database) has a limit of 4000 points in a polygon
      • OA (e.g. IC61 and later) does not have a limit
    • Various functions (such as the dbLayer functions) will automatically split a large polygon into pieces to ensure that it stays beneath a point limit. It should not crash (and I'm not aware of any crash issues, so maybe it is specific to the version you're using?). I just created an 8000 point polygon in IC616, and was able to run dbLayerSize on it with no problems.
    • In IC61, by default dbLayerSize will split with a maximum number of vertices of 195. However, I could quite happily do:
         b=dbLayerSize(cv "Metal2" a 50 10000)
      which sizes up by 50um and creates a single polygon because the resulting polygon with 8000 points has fewer than 10000 points.
    • Even in IC5141, the fact that you are limited to 4000 points shouldn't actually cause you any problems because you would operate on the complete list of shapes that you build and the tool will deal with them properly as if they were merged.
    • Tom's suggestion of using the magnification factor in (say) dbMoveFig to scale it up won't help, because that is a scaling rather than a sizing (which are different options). With scaling, it's just like a zoom - it doesn't cause any omission of narrow tracks or merging of narrow gaps. Note that mag of anything other than 1 cannot be used on instances in OA (only on transformations of shapes).

    Regards,

    Andrew.

Reply

  • A few points:

    • Tom is right - this is not an "Ask Andrew" forum - there are others who respond in this forum, and that's really the point - it's a community forum. I reply to these posts when I have a moment (it's not part of my job). Sure I probably respond more than most, but others do too.
    • That said, please don't send me private messages asking for responses for things that can equally well be asked in the forums or to customer support. Given that I do have a full time job here in Europe, I don't really have the bandwidth to deal with direct unsolicited private emails or personal messages (obviously I make exceptions, but it's not a scalable solution for every CIC engineer in the world to send me direct questions - this is why we have customer support).
    • You didn't mention which version you are using. There are some limitations:
      • CDB (the IC5141 and before database) has a limit of 4000 points in a polygon
      • OA (e.g. IC61 and later) does not have a limit
    • Various functions (such as the dbLayer functions) will automatically split a large polygon into pieces to ensure that it stays beneath a point limit. It should not crash (and I'm not aware of any crash issues, so maybe it is specific to the version you're using?). I just created an 8000 point polygon in IC616, and was able to run dbLayerSize on it with no problems.
    • In IC61, by default dbLayerSize will split with a maximum number of vertices of 195. However, I could quite happily do:
         b=dbLayerSize(cv "Metal2" a 50 10000)
      which sizes up by 50um and creates a single polygon because the resulting polygon with 8000 points has fewer than 10000 points.
    • Even in IC5141, the fact that you are limited to 4000 points shouldn't actually cause you any problems because you would operate on the complete list of shapes that you build and the tool will deal with them properly as if they were merged.
    • Tom's suggestion of using the magnification factor in (say) dbMoveFig to scale it up won't help, because that is a scaling rather than a sizing (which are different options). With scaling, it's just like a zoom - it doesn't cause any omission of narrow tracks or merging of narrow gaps. Note that mag of anything other than 1 cannot be used on instances in OA (only on transformations of shapes).

    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.