Stats

  • Locked Locked
  • Replies 4
  • Subscribers 143
  • Views 14637
  • 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

Skew edges created in IC6.1.5

Eugene201

Hi,

I have a question about path creation. When I create a path (in IC5.1) with "round" endType the path generates all edges at 45 degree angles. However, when I do the same thing in IC6.1.5 the edges get generated at angles other than 45 degrees. (This is the case only for some path widths such as 0.3 0.6 and 1.2 to name a few). I have also created the same path using rodCreatePath with "octagon" endType and the result is the same. In IC6.1 the rounded edges create skew lines and in IC5.1 the function works correctly. Any suggestions that you may have regarding this would be greatly appreciated. 

Eugene 

Parents
  • Andrew Beckett

    Eugene,

    I hadn't really understood what you'd meant by "skew edges". Also, you'd not said that the path was at 45 degrees, which I think is key to the issue.

    Anyway, I've reproduced the issue. What I did was use the code you used above, and then convert the path to a polygon. Using this SKILL code:

    {foreach(map point append(car(geGetSelSet())~>points car(geGetSelSet())~>points)
     when(cadr(point) println(mapcar('difference car(point) cadr(point))))) t}

    with the polygon selected, it displays the differences between successive points (it repeats the point list twice, to allow you to get the difference between the last point and the first - I was being lazy). In IC5141 I get:

    (-0.07 0.07)
    (-0.142 0.0)
    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)
    (0.0 0.142)
    (-0.07 0.07)
    (-0.142 0.0)
    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)

    You can see all these deltas are either orthogonal (one of the x or y is 0.0) or 45 degree (the absolute value of the x and y are the same). With IC615, I get:

     (-5.0 -5.0)
    (0.001 -0.143)
    (0.07 -0.07)
    (0.141 0.001)
    (5.0 5.0)
    (-0.001 0.143)
    (-0.07 0.07)
    (-0.141 -0.001)
    (-5.0 -5.0)
    (0.001 -0.143)
    (0.07 -0.07)
    (0.141 0.001)
    (5.0 5.0)
    (-0.001 0.143)
    (-0.07 0.07)

    As you can see, a number of the "orthogonal" deltas are not quite orthogonal - the x or y is +/-0.001

    However, in IC616 (ISR1), I get:

    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)
    (0.0 0.142)
    (-0.07 0.07)
    (-0.142 0.0)
    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)
    (0.0 0.142)
    (-0.07 0.07)

    So it appears to be fixed there (I couldn't find any reports of this, so maybe it was uncovered during some product validation). The same is true if I create the shape in IC615 and then view it in IC616 - it's fixed.

    However, I just found that the interactive "Convert to Polygon" seems to be broken in IC616 with this shape (it was OK if I used dbConvertPathToPolygon instead). So I've filed CCR 1185948 for that issue.

    Kind Regards,

    Andrew.

Reply
  • Andrew Beckett

    Eugene,

    I hadn't really understood what you'd meant by "skew edges". Also, you'd not said that the path was at 45 degrees, which I think is key to the issue.

    Anyway, I've reproduced the issue. What I did was use the code you used above, and then convert the path to a polygon. Using this SKILL code:

    {foreach(map point append(car(geGetSelSet())~>points car(geGetSelSet())~>points)
     when(cadr(point) println(mapcar('difference car(point) cadr(point))))) t}

    with the polygon selected, it displays the differences between successive points (it repeats the point list twice, to allow you to get the difference between the last point and the first - I was being lazy). In IC5141 I get:

    (-0.07 0.07)
    (-0.142 0.0)
    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)
    (0.0 0.142)
    (-0.07 0.07)
    (-0.142 0.0)
    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)

    You can see all these deltas are either orthogonal (one of the x or y is 0.0) or 45 degree (the absolute value of the x and y are the same). With IC615, I get:

     (-5.0 -5.0)
    (0.001 -0.143)
    (0.07 -0.07)
    (0.141 0.001)
    (5.0 5.0)
    (-0.001 0.143)
    (-0.07 0.07)
    (-0.141 -0.001)
    (-5.0 -5.0)
    (0.001 -0.143)
    (0.07 -0.07)
    (0.141 0.001)
    (5.0 5.0)
    (-0.001 0.143)
    (-0.07 0.07)

    As you can see, a number of the "orthogonal" deltas are not quite orthogonal - the x or y is +/-0.001

    However, in IC616 (ISR1), I get:

    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)
    (0.0 0.142)
    (-0.07 0.07)
    (-0.142 0.0)
    (-5.0 -5.0)
    (0.0 -0.142)
    (0.07 -0.07)
    (0.142 0.0)
    (5.0 5.0)
    (0.0 0.142)
    (-0.07 0.07)

    So it appears to be fixed there (I couldn't find any reports of this, so maybe it was uncovered during some product validation). The same is true if I create the shape in IC615 and then view it in IC616 - it's fixed.

    However, I just found that the interactive "Convert to Polygon" seems to be broken in IC616 with this shape (it was OK if I used dbConvertPathToPolygon instead). So I've filed CCR 1185948 for that issue.

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