create path in 45 degree -- off-grid in the corner points?? VLE

When we draw a metal-path with 45 degree angle in VLE, only the
centerline corner points are on-grid. The other 2 points (corners)
where the bend occurs are off-grid. Is it not a problem because unless
all the points (corners) are on-grid, the geometry can not be
fabricated?


Thanks, Manju

 

Well, if that were the case, any design with 45 degree paths would not be
manufacturable - which clearly isn't the case. Obviously the edge vertices have
to be off grid, because that's the way the unverse was made (complain to Euclid
or God if you're not happy).

Normally it doesn't really cause a problem - although generally there will be some rounding
errors in certain tools. The mask making equipment generally has finer resolution than
the actual grid, and anyway any error with the actual points will be miniscule compared
with the fuziness of the actual silicon...

Andrew.

 

The 45-deg sections of a path have to have a different width compared
to the manhattan sections to stay on grid and Opus paths don't have
that capability. Off-grids are still possible at intersecting 45's,
and if the ends of the path are 45's.

We overcome this problem by having a custom bus pcell creator, that
handles 45 degree paths by replacing the 45 degree paths to
polygons(snapping to the grid as required).
Also, cadence supplies a skill code that converts these off grid
diagonal paths to ongrid by growing the path widths till they become
ongrid.

The calculation of rounding of a path by cadence is done on the basis
of DBUPerUU( 2*(1/DBUPerUU)) and not by manufacturinggrid.

I did file a enhancement PCR 281306, quite a while back indicating
this "issue"

Partha

 

Hello,

I disagree with Andrew. Although the manufacturing should probably be
possible, most design centers don't accept off-grid errors in the GDSII
file, i.e. you have to get rid of them in your design.

The most elegant way is to write a PCell as done in Partha's company. In
my place we were not aware of the Cadence SKILL code to convert this to
polygons, so one of my colleagues wrote a similar script. Can I find the
Cadence code on Sourcelink, just to compare?

Paul

 

Yes you can, I filed a SR to request that( It is not available
directly from Sourcelink though, not yet)

Partha

 

Partha,

Can you get me the SKILL code which on-grids the points?

Thanks, Manju

 

Manju,
I will not be able to send the code since it was not developed by me.
Am sorry. But you could ask cadence for the source code that converts
the offgrid paths to on grid by sizing them

Thanks
Partha

 

I have some C code that converts a path into a polygon. It might help. This
code can mostly be converted to SKILL line-by-line. It seems to work for my
application, but let me know if you spot an error or if you know of a
cleaner way to do this.

Frank

void path_to_polygon(path &path0, polygon &poly) {

unsigned i, pa, pb, npts;
double width, width2, b_ext = 0.0, e_ext = 0.0, vx, vy, ux, uy, vmag, umag,
denom, x1, x2, y1, y2, l1, l2;
point *points, *points2;

npts = 2*path0.npts;
poly.layer = path0.layer;
poly.npts = npts;
width = path0.width;
width2 = 0.5*width;
pa = 0;
pb = npts - 1;
points2 = path0.points;
points = new point[npts];

if (path0.type == PATH_TYPE2) { // begin and end extension by half width
b_ext = 0.5*width;
e_ext = 0.5*width;
}
for (i = 0; i < path0.npts; ++i) {
if (i == 0) {
vx = points2[i+1].x - points2.x;
vy = points2[i+1].y - points2.y;
}
else {
vx = points2.x - points2[i-1].x;
vy = points2.y - points2[i-1].y;
}
vmag = sqrt(vx*vx + vy*vy);
vx /= vmag;
vy /= vmag;

if (i == 0) { // start
points[pa].x = points2.x - b_ext*vx + width2*vy;
points[pa].y = points2.y - b_ext*vy - width2*vx;
points[pb].x = points2.x - b_ext*vx - width2*vy;
points[pb].y = points2.y - b_ext*vy + width2*vx;
}
else if (i == (unsigned)(path0.npts-1)) { // end
points[pa].x = points2.x + e_ext*vx + width2*vy;
points[pa].y = points2.y + e_ext*vy - width2*vx;
points[pb].x = points2.x + e_ext*vx - width2*vy;
points[pb].y = points2.y + e_ext*vy + width2*vx;
}
else { // line-line intersection
ux = points2[i+1].x - points2.x;
uy = points2[i+1].y - points2.y;
umag = sqrt(ux*ux + uy*uy);
ux /= umag;
uy /= umag;
denom = ux*vy - vx*uy;

if (denom == 0.0) { // should be an invalid path
printf("Warning: Path has three colinear points.\n");
points[pa] = points[pa-1]; // duplicate last point
points[pb] = points[pb+1];
}
else {
x1 = points2.x + width2*vy;
x2 = points2.x + width2*uy;
y1 = points2.y - width2*vx;
y2 = points2.y - width2*ux;
l1 = x1*(y1 + vy) - (x1 + vx)*y1;
l2 = x2*(y2 + uy) - (x2 + ux)*y2;
points[pa].x = (ux*l1 - vx*l2)/denom;
points[pa].y = (uy*l1 - vy*l2)/denom;

x1 = points2.x - width2*vy;
x2 = points2.x - width2*uy;
y1 = points2[i].y + width2*vx;
y2 = points2[i].y + width2*ux;
l1 = x1*(y1 + vy) - (x1 + vx)*y1;
l2 = x2*(y2 + uy) - (x2 + ux)*y2;
points[pb].x = (ux*l1 - vx*l2)/denom;
points[pb].y = (uy*l1 - vy*l2)/denom;
}
}
++pa;
--pb;
}
poly.points = points;
}[/i][/i]

 

Well, it depends. Usually there's a requirement to either have the centre line or
the edges on grid, but not both - but as with all things, your mileage may vary...

Andrew.

 

It will be your fracturing software, and not VLE, that decides how your
paths are converted to trapezoids for imaging on the reticle. So how you
see those paths displayed in VLE will have no bearing on what you see on the
reticle.

If you convert, through any software, your 45 degree paths to on-grid
polygons, then you have to worry about the square root of 2. Basically, you
will have two choices: the 45 degree portions will either be thicker or
thinner than what the originally specified width was.

This may be of some concern to you if you have bent gates, and your circuit
simulations are relying on the original path width. So if you end up with
thinner or thicker gates, the speed of your circuit will vary. Normally,
this may only be of some concern when you have a low density of
manufacturing grid points relative to the width of your path. You may have
similar concerns with metal, though not of the same order as the basic speed
of your gates.

spaller

 

being a longtime Cadence Skill programmer/CAD Engineer I have run across
this problem more then I like... the best solution is a piece of software
that has a GREAT tool for generating the paths ONGRID.... it does this by
way of letting you draw the path like you would normally, then it converts
it to a polygon and fixes the offgrid 45s, it can do this by way of the
knowledge that you were intending to have the object as a path...
It also allows you to re-enter the flattened path as if it were a normal
path.... VERY NICE.... the name of the software was the STX Toolbox when I
last used it, you can get the software from Dave Truty at
www.stxcadware.com.... tell him danielof said to call and he will set you up
with a demo...! good luck!

Danielof