Stats

  • Locked Locked
  • Replies 1
  • Subscribers 143
  • Views 8793
  • 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

Arithmetic calculation going wrong.

Abhishek G V

Hello everyone,

I'm a student started working on SKILL automation, I m trying to write a skill program for automating the results of basic layout reviews, and i m facing issue in comparing float data. for Some data the comparison is successful, but for some even the data is same it's not showing it's same.

Case 1:

K=0    lly(2.660000) != tly[0](-0.140000)

K=1    lly(2.660000) != tly[1](0.420000)

K=2    lly(2.660000) != tly[2](0.980000)

K=3    lly(2.660000) != tly[3](1.540000)

K=4    lly(2.660000) != tly[4](2.100000)

K=5    lly(2.660000) == tly[5](2.660000)    ury(2.940000) != tuy[5](2.940000)

K=6    lly(2.660000) != tly[6](3.220000)

K=7    lly(2.660000) != tly[7](3.780000)

K=8    lly(2.660000) != tly[8](4.340000)

K=9    lly(2.660000) != tly[9](4.900000)

lly=2.660000    ury=2.940000

Metal-2 should be on track.

Case 2:

K=0    lly(2.100000) != tly[0](-0.140000)

K=1    lly(2.100000) != tly[1](0.420000)

K=2    lly(2.100000) != tly[2](0.980000)

K=3    lly(2.100000) != tly[3](1.540000)

K=4    lly(2.100000) == tly[4](2.100000)    ury(2.380000) == tuy[4](2.380000)

K=5    lly(2.100000) != tly[5](2.660000)

K=6    lly(2.100000) != tly[6](3.220000)

K=7    lly(2.100000) != tly[7](3.780000)

K=8    lly(2.100000) != tly[8](4.340000)

K=9    lly(2.100000) != tly[9](4.900000)

Metal-2 is on track.

here's the result of my program,

docs.google.com/.../edit

  • You've not shared your code - not entirely sure how you would expect somebody to debug what's wrong with your code from just the output - but almost certainly this is a classic floating point rounding error mistake. It's always dangerous to compare floating point numbers with == in any language using IEEE floating point arithmetic (most languages).

    There are numerous posts on this with SKILL in particular and a google search would find many on the problem in general. For example here's a couple:

    If these are database coordinates, the safest way to compare is to get the cellView DBUperUU and round to integer before comparison. For example:

    procedure(CCFcompareXorY(n1 n2 DBUPerUU)
      round(n1*DBUPerUU)==round(n2*DBUPerUU)
    )

    cvId=geGetEditCellView()
    DBUPerUU=cvId~>DBUPerUU
    ury=2.38
    tuy=2.38+1e-13 ; an example of a slight rounding error
    ury==tuy ;  returns nil
    CCFcompareXorY(ury tuy DBUPerUU) ; returns t

    There is also the nearlyEqual() function, but to be honest when comparing database values such as coordinates (which are really stored as integers), it's best to convert them to integers before comparing - that's going to be the best approach. nearlyEqual is better for general floating point comparison.

    Regards,

    Andrew

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.