Layout scaling and inconsistent shape dimensions issue.

I suspect the most likely scenario where things are ending up at 0.556 width is if they were paths or pathSegs to start off with, and your database has a DBUPerUU of 1000 (i.e. a database resolution of 1nm). Paths and pathSegs need to have a width which is an even number of database units, and so you cannot have 0.555 as the width. For other polygons and rectangles, it's the points themselves that are scaled not the width, but I would expect the rounding error to truncate in the same direction, but I'm not sure without doing an experiment (maybe if the shapes are centred around the 0 x or y coordinate then they might round in different directions to get onto the database grid). Without seeing some example data, it's hard to be sure...

Andrew

Hi Andrew,

Thanks for your reply!

I just checked some more contacts (these contacts are also rectangle types) and found similar issues. Not sure if you can see the images—I ran into some trouble uploading them. I noticed that when scale up, some contacts measure 0.1 in size while others are 0.099. Moreover, all contacts with a width of 0.099 are aligned in the same column (sharing identical x-axis coordinates). This makes me suspect it might be related to the shape's bounding box coordinates.

I did some experimentation (to avoid having to think of a good example) and created 1 million rectangles of width/height 0.09 at random coordinates between +/- 100um, and then streamed this out and streamed back in with a scale factor of 1.11.

I then analysed the widths and heights of the resulting shapes and I had approximate 200,000 shapes with a width or height of 0.099 and 1,800,000 shapes with a width or height of 0.1 (the total is twice the number of shapes because I had two dimensions to analyse).

Picking a couple of examples. This original shape (here's the bBox):

((-99.742 99.985) (-99.652 100.075))

would be scaled to this (with no rounding):

((-110.71362 110.98335) (-110.61372 111.08325))

which when rounding to the 1000 DBUPerUU would be:

((-110.714 110.983) (-110.614 111.083))

This has a width and height of 0.1.

Now looking at this original shape:

((-98.804 99.995) (-98.714 100.085))

This would be scaled to (without rounding):

((-109.67244 110.99445) (-109.57254 111.09435))

You can see from the x-coordinates that one is just below half of 0.001 and one is just above, so they will round in different directions:

((-109.672 110.994) (-109.573 111.094))

this shape has a width of 0.099 and a height of 0.1.

This is inevitable because of the scale factor of 1.11 - when you are dealing with shapes with a resolution finer than 0.1 (i.e. have a coordinate that is made up of hundredths or thousandths of microns as part of the coordinate), they will scale to a number which includes digits beyond the database resolution and hence will snap to grid - and these could snap in opposite directions depending on the coordinate values.

As for fixing this with SKILL - it rather depends on what you are expecting it to do in every scenario - conceivably you could correct the widths of rectangles, but what do you do with polygons and other shapes?

Andrew

I did some experimentation (to avoid having to think of a good example) and created 1 million rectangles of width/height 0.09 at random coordinates between +/- 100um, and then streamed this out and streamed back in with a scale factor of 1.11.

I then analysed the widths and heights of the resulting shapes and I had approximate 200,000 shapes with a width or height of 0.099 and 1,800,000 shapes with a width or height of 0.1 (the total is twice the number of shapes because I had two dimensions to analyse).

Picking a couple of examples. This original shape (here's the bBox):

((-99.742 99.985) (-99.652 100.075))

would be scaled to this (with no rounding):

((-110.71362 110.98335) (-110.61372 111.08325))

which when rounding to the 1000 DBUPerUU would be:

((-110.714 110.983) (-110.614 111.083))

This has a width and height of 0.1.

Now looking at this original shape:

((-98.804 99.995) (-98.714 100.085))

This would be scaled to (without rounding):

((-109.67244 110.99445) (-109.57254 111.09435))

You can see from the x-coordinates that one is just below half of 0.001 and one is just above, so they will round in different directions:

((-109.672 110.994) (-109.573 111.094))

this shape has a width of 0.099 and a height of 0.1.

This is inevitable because of the scale factor of 1.11 - when you are dealing with shapes with a resolution finer than 0.1 (i.e. have a coordinate that is made up of hundredths or thousandths of microns as part of the coordinate), they will scale to a number which includes digits beyond the database resolution and hence will snap to grid - and these could snap in opposite directions depending on the coordinate values.

As for fixing this with SKILL - it rather depends on what you are expecting it to do in every scenario - conceivably you could correct the widths of rectangles, but what do you do with polygons and other shapes?

Andrew

Hi Andrew,

Thank you for your detailed analysis. I've learned a lot.

I plan to write a script to modify the width of rectangles using SKILL. Since almost all the shapes in my design are rectangles, this method is well-suited for my needs.