Pin width change

HI Gurup,

That sound's like one of these infamous rounding issues to me, try

(printf "%2.20f" p_width)

...and you will most likely find that p_with is just close to but not exactly 0.2.

There is a solution for this problem:

https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od0000000naf2EAA&pageName=ArticleContent

Max

And in  different coordinate the p_width is changing .. and in some coordinate its struck one value

One way to deal with these floating point rounding errors (which have been covered many times in these forums and elsewhere for numerous programming languages - this is not an issue unique to SKILL) is to introduce an error term (epsilon) in the comparisons. In this case I set it to a small number (e.g. one tenth of your probably database unit - often people have a DBU of 1nm, so I set it to 0.1nm). Then make the comparison including this term:

epsilon=1e-4 ; assuming you have a DBUperUU of 0.001 this would be a tenth of the resolution (could be tighter still)
cond(
  (p_width<0.2-epsilon p_width=0.5)
  (p_width>=0.2-epsilon && p_width<0.6-epsilon p_width=0.6)
  (p_width>=0.6-epsilon && p_width<1-epsilon p_width=1)
  (p_width>=1-epsilon && p_width<2-epsilon p_width=2)
  (p_width>=2-epsilon p_width=.2)
);end cond

By the way, your second branch in the cond statement had (I believe) the comparison the wrong way around (it had <= rather than >=)

Regards,

Andrew.

Thank you very much mbracht and Andrew

Same scripts works for path/pathSeg width , but only for Pin its giving error even for floatnum path width

Gurup said:

Same scripts works for path/pathSeg width , but only for Pin its giving error even for floatnum path width

There's probably a difference in the floating point calculation in the two cases. One you're doing a difference of the bounding box, and in the other case you're directly reading the width from the database. The subtraction is likely to lead to a floating point rounding error, whereas the direct database access isn't. So this is not unexpected.

As I've said here (and in many, many other places), this is something that would happen in most programming languages and is well covered across the internet. Coding it similar to the way that I proposed will defend against such rounding errors.

Andrew.

I searched for  same problem, but don't know what search exactly :)    Ok Thanks For the info  Andrew. 

Andrew,

How about creating some sticky post on such topics? This can ensure more hit ratio of catching people's eye and such questions can be avoided.

-Ramakrishnan

Hi Ramakrishnan,

Two issues:

1. Nobody reads the forum guidelines which are a sticky post at the top of each forum (OK, I'm sure it's not "nobody", but given the number of times posts are made in violation of the guidelines, I suspect very few read them)
2. This specific issue is quite hard to cover in a way that you'd actually think of it when you hit an issue. There are an enormous range of symptoms and situations where it occurs, and the summary would tend to be "never do an equality check on floating point numbers" which is describing the answer, not the problem - so you wouldn't necessary spot that this is relevant.
3. There are lots of common topics that come up - this is just one of them. Cherry picking those is quite hard
4. I can't count to two.

In general the search ought to find lots of cases, but that tends on only be where you've got a situation with similar symptoms.

On the support site, we have some FAQs to try to address such common topics, but I normally find it's the search that finds things, not looking at the FAQs.

Andrew.