Different Behavior of leChopShape Command in ic 06.18.050 & in icadvm 18.10.090 !!!

Hi Sonu,

I'd be surprised if there was a difference - the releases should track anyway, and whilst your ICADVM release is 4 hotfix versions later, but I would be surprised if there were any fixes in such a long-standing function (I couldn't find anything from a quick search. I'm guessing that maybe the data is not identical in both release streams?

If you can give some indication of what you're doing (e.g. a screenshot, and ideally a capture of the arguments to leChopShape and info about the database object being chopped - e.g. the ~>?? of the object would help, ideally as text in the post rather than an image), I may be able to provide more insight. If you can't do that, I suggest you contact customer support.

Andrew

Hello Andrew,

Thanks for the quick response. I have a very good and simple Example to summarize this problem .

Let Suppose , I am having only a single Rectangle shape in my layout cell view and its has a bounding Box ((0 0) (5 5)) . I want to chop this shape from the left most point (I mean from Origin to 2um height and 2um right side). As Shown Below in the Image:

I am running following commands in both the version and getting different result :-

In Icadvm 18.10.090

cv = geGetWindowCellView

a = car(cv~>shapes)  --> as a single Rectangle shape is there

 leChopShape(a list(0:0 0:2 2:2 2:0) t t)

Its Result in a chopped Shape in inCadvm and chopped shapes is returned as a database object.

in IC Version 06.18.050 :- 

The Same Steps Result in a warning that chopped shapes results in self intersecting shapes and self intersecting shapes are not chopped.

The Output Shape is same as Input shape as Chop Operation is not Performed.

Hopefully , I am now clear enough with the problem statement . Let me Know in case something not clear.

Thanks in advance Andrew,

Regards

Sonu     

Hi Sonu,

I've reproduced it, and it's broken in IC6.1.8 and ICADVM18.1 from the initial release up until ISR8, and fixed in ISR9 - so it works in both IC6.1.8-64b.500.9 and ICADVM18.1-64b.500.9. I've tested it in a range of different versions.

Having then discovered when it was fixed, I located the CCR (Cadence Change Request) where this was corrected - it was reported as it also affects interactive chops:

2157065 : Not able to chop shape from exact low left point

Note that this doesn't just mean that you can rotate the point list around and start from a different place. If the lower left of the chop region was slightly to the lower left of 0:0, then it works. The reason was due to some infrastructure changes and it was a little tricky to resolve, but it took a while before it was noticed because it only happens in very specific situations.

Andrew.

Hello Andrew,

Thanks for Sharing all the detailed info . Just a query for my understanding (as i am not from software development Field) how to read a IC or Icadvm Sub Version or how this Sub Version are named ?

For Example :- ic6.1.8-64b.500.9  --> Where 64 stands for 64 Address bit but what about 500 and 9 ?

Regards

Sonu 

Hi Sonu,

The first bit (IC6.1.8/ICADVM18.1) is the major version; the -64b is an optional bit (sort of) which indicates whether it's the 64-bit flavour (I say "sort of" because we only have 64-bit Virtuoso nowadays); the part after that is the sub-version. What happens is that in the initial "base" release of the software, there's a sub-version dependent upon how many builds during the development of the main release stream that there were before it was released - for example IC6.1.8-64b.83 and IC6.1.7-64b.78. We then have a convention that .500 means it's a hotfix, and the number after that is the sequential hotfix or "ISR" (incremental software release) number. So when you see those numbers above, that's often referred to as "ISR9".

Hope that helps!

Andrew

Hello Andrew,

Indeed , It was really helpful and very detailed. Thanks for the all the help.

have a good day ahead,

Regards

Sonu