Stats

  • State Not Answered
  • Locked Locked
  • Replies 2
  • Subscribers 9
  • Views 2928
  • 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

PCell Designer: lor Geo Query Command

EMaz

Hello,

I am seeing outputs by an "lor" Geo Query command depending on the technology file. the "lo

Common starting point:

  • I have a 1umx2um rectangle with 2 quarters of an elliptical polygon (half circles) on both the top and bottom. The 3 shapes are all drawn in the same layer.
  • I add a polygon command to create a new layer. Within the polygon command I use all 3 shapes as the source. The Geo Query expression is 3 nested lines. The inner most line is a "layer" command which identifies the 3 shapes (rect + 2 half circles). The next line is an "lor" command intended to merge the shapes. The outer most line is a "grow" command.
  • Layer commands behave the same but the outputs of the "lor" command deviate.
  1. Technology file "A"
    1. not sure this matters but this technology has a grid of 0.005um
    2. the "lor" command merges the 3 shapes
  2. Technology file "B"
    1. this technology has a grid of 0.001um
    2. the "lor" command does not merge the shapes, instead it create a polygon with a vertical line towards the right side. The subsequent grow of course does not grow uniformly.

Do you know what could be causing this delta? 

Regards,

Erika

Parents
  • 0

    Erika,

    I managed to follow what you are describing (some pictures would have helped!). Anyway, this is certainly related to the grid. 

    Here's what I get with a grid of 0.005:

    and with a grid (I just used "change grid" to alter it):

    This is a consequence of the fact that the underlying database layer logical operations split the polygons into multiple shapes if there are more than 195 vertices. Unfortunately the grow operator doesn't handle this correctly (potentially we could deal with this internally - I'll speak with the team tomorrow). Anyway, the good news is that there is a way to handle this. Firstly, add a skill command at the beginning of the code with the following:

    gqlSetMaxPoints(100000)

    (doesn't necessarily have to be as large as one hundred thousand as you won't hit that with polygons this size, but much bigger than 195). With this, you'll get a smooth polygon with a split in it still:

    The split is because the grow operator is still splitting with the default number of vertices (I'll raise this too with the team). This can be fixed by changing the geo expression from:

    To:

    In other words, another lor around the grow.

    At some point (possibly in the next major release) we may increase the default number of vertices to minimise these issues - we've been cautious about doing so in a minor release as it may impact existing PCells. The gqlSetMaxPoints() is our supported way of handling this for now. Setting it in a PCell affects geo operators for the remainder of the PCell.

    Regards,

    Andrew

Reply
  • 0

    Erika,

    I managed to follow what you are describing (some pictures would have helped!). Anyway, this is certainly related to the grid. 

    Here's what I get with a grid of 0.005:

    and with a grid (I just used "change grid" to alter it):

    This is a consequence of the fact that the underlying database layer logical operations split the polygons into multiple shapes if there are more than 195 vertices. Unfortunately the grow operator doesn't handle this correctly (potentially we could deal with this internally - I'll speak with the team tomorrow). Anyway, the good news is that there is a way to handle this. Firstly, add a skill command at the beginning of the code with the following:

    gqlSetMaxPoints(100000)

    (doesn't necessarily have to be as large as one hundred thousand as you won't hit that with polygons this size, but much bigger than 195). With this, you'll get a smooth polygon with a split in it still:

    The split is because the grow operator is still splitting with the default number of vertices (I'll raise this too with the team). This can be fixed by changing the geo expression from:

    To:

    In other words, another lor around the grow.

    At some point (possibly in the next major release) we may increase the default number of vertices to minimise these issues - we've been cautious about doing so in a minor release as it may impact existing PCells. The gqlSetMaxPoints() is our supported way of handling this for now. Setting it in a PCell affects geo operators for the remainder of the PCell.

    Regards,

    Andrew

Children

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.