Large polygons and odd cell rotations in Virtuoso

Hi,
My research group is creating large circular shapes for mask layouts on
a fine grid. My first attempt to create these was to use
dbCreateEllipse()/dbCreateDonut() and then
dbConvertEllipseToPolygon()/dbConvertDonutToPolygon(). The problem is that
the results contain diagonal lines that must be split up into an
astronomical number of horizontal and vertical segments (on a 1nm grid) by
the mask writing tool, and the last mask took forever to write.

What we would like to do is to create the donut on about a 20nm (instead of
1nm) grid with only horizontal and vertical lines for an orthogonal polgyon.
So I wrote some SKILL code to read in the donut polygon and create a new
polygon with diagonal lines replaced by x/y steps on a 20nm grid. However,
some of the resulting polygons contained more than 4000 points and Virtuoso
(ICFB 4.46) said they were invalid and the max was 4000. Is there any way
around this vertex limit, or any way to split a polygon with ~10,000 points
into smaller polygons with <4000 points efficiently? My best solution was to
split the polygons into a huge number of rectangles with some SKILL code and
then use leMergeShapes() to get polygons. This takes alot of time and memory
considering there are around 100K rectangles to merge.

We eventually had someone else make the polygons for us out of a number of
sections to avoid this problem. What they did was to divide the donut into
16 angular segments, create a polygon one segment, and use 16 instances
representing each 22.5 degree slice to form the final ring. While this was
created easily in L-Edit, converted to GDS2, and sent to us, Cadence refused
to read the odd cell rotations. Is there any way to have Cadence Virtuoso
stream in a GDS2 layout with cell rotations of 22.5 degrees? Are there any
(relatively free) tools out there that will partially flatten only the cells
with these odd rotations and write the result back out to GDS2? I don't
understand why these rotations cause such a problem in Cadence.

Any solutions/suggestions will be appreciated. Thank you.

Frank Gennari

 

gennari,
My layout editor(slam) can read your gds & smash it. The editor
supports any angle instance placements. I also have a donut command,
and split command and a any angle polygon to orthogonal polygon command.
I think with those 3, you could fairly easily create your own structures.
Pricing for universities is quite low. Contact me if interested. I can
set you up with an tmp key to try it.

Mike Stabenfeldt
Stabie-Soft

 

Frank,

Cadence Virtuoso supports only manhattan rotations for cell instances.
All angle rotations are presently supported only for shapes.

I (and others) will certainly appreciate that Cadence change this.
Especially that GDSII is fully supporting this all angles from
a long time. As you may know GDSII is owned by Cadence !

===================
Kholdoun TORKI
http://cmp.imag.fr
===================

 

I didn't know anything about this so I did a little digging this Saturday.

I found product-change request PCR 250206 which states:
01-16-2003 01:33:06
The ability to stream in non-orthogonal instances has been implemented
in our forthcoming DFII StreamIn engine on OpenAccess (it's a tool named
XStream). XStream will be available in the beta release scheduled for
the end of this month.

I've been using XStream for months on our flow testcase Raptor, simply
because it was so much faster than PIPO; but, I hadn't ever used it for
non-orthogonal instances. If you ftp your stream file
ftp://ftp.cadence.com/public/
& email me (to my regular business address, not to this spam-trap address),
I might be able test it for you by running XStream in DFII on OpenAccess.

 

I thought that sooner or later Cadence would support arbitrary cell
rotations. I mean, why not? The rotations can easily be dealt with using a
3x3 rotation matrix that transforms all of the points. I've done this myself
in some other code.

I would send you the layout, but it contains confidential information and
I'll have to ask the creators about sending it out to be converted into a
different format, flattened, etc. So far three people have offered to
convert it for me (thank you all for the offers), but I'm not sure I have
permission to send it outside of UC Berkeley EECS.

Frank

 

John,

I will send you a GDSII file containing a layout example
with non-orthogonal instances.
It will be a very simple structure with no IP inside.

==================
Kholdoun TORKI
http://cmp.imag.fr
==================

 

This is a good news !

It means that also Virtuoso will support the all angles rotations
for instances.
Do you know if Skill commands : leHiRotate, leHiMove, leHiCopy, ...
have been updated with the all angles options.

==================
Kholdoun TORKI
http://cmp.imag.fr
==================

 

Frank,

There is a free demo software which supports all angles
for instances :
http://www.wieweb.com/nojava/downloadframe.html

I use it from time to time on my laptop to display some
small layouts. (too slow for large designs).

This is not exactly the answer to you question, but at
least give you a help (for free) to view a layout using
all angles instances.
I was a bit frustrated when I received last year a design
from a customer using all angles instancing, and I was enable
to stream in it in Cadence Virtuoso. I asked te customer
to flatten the concerned cells and send me back a new
GDSII file. (He used at that time Tanner/L-Edit).

==================
Kholdoun TORKI
http://cmp.imag.fr
==================

 

Kholdoun,
While not free, the viewer my company has can also
run on a laptop & view large gds files (Multi-gigabyte sized)
on larger machines. It also handles instances placed at any angle.
The layout viewer is only $149, and includes future updates.
Nearly free, and not a demo version like the wieweb software.

Mike Stabenfeldt
http://www.stabie-soft.com

 

The wieweb viewer seems to be slow because it doesn't do sub-pixel
filtering. Also, I couldn't get it to open anything (CIF or GDS2) over about
20MB. It just sits there for many minutes using 100% CPU and doing nothing.
The best free viewer I've found for PCs is Dolphin Integration's SOC GDS
Seduction, at http://www.dolphin.fr/medal/socgds/socgds_free_overview.html.
Some of the functions are disabled but it can read just about any GDS2
layout.

I'm working on a layout viewer myself which I plan to make open source
software. I'm trying to find other free PC viewers to test it against, and
the goal is to make my viewer faster and more memory efficient that the
others while maintaining the ability to read everything in the GDS2 file
(including arbitrary cell rotations).

Frank

 

If you're going to write your own there's a few things you need to
think about if you want it to be fast. You want a means to rapidly
get just the data that will be seen (i.e. only data that overlaps
the viewport). For than a good spatial database is needed - I use
a modified KD tree which allows very fast reqion query. You can
further speed things up by filtering out shapes that are very small
i.e. less than a few pixels. You'll need fast transformation code
to handle cell rotations and there are many ways to get better
performance than using a general 3x3 matrix as the textbooks
describe. Lastly you want a good 2D graphics library - I use Qt
from Trolltech which means my code runs on most platforms including
Windows and Mac OS.

With care you should be able to read GDS2 100x faster than DF2's
stream in. Good luck!

- Keith

 

Keith,
Thank you for the input. I already have most of these features built
into my viewer. I'm not exactly sure what a KD tree is, though I can
probably find info on it with a Google search. I subdivide large cells into
two or more levels of virtual cells, which has less overhead than a binary
tree. For instance, if a cell contains 1 million objects I divide it into
either 1000 cells of approx. 1000 objects, or 100 cells each containing
about 100 other cells, which contain around 100 objects. Either way works
well, and iterating over as many as 1000 cells still only takes a few
milliseconds. I believe the display time is mostly limited by the fill rate
of the video card or the AGP bandwidth.

I filter out shapes less than about half a pixel, but the threshold can be
changed by the user. Polygons only a few pixels in size are drawn as
rectangles (if area(poly)/area(poly bbox) > some threshold I can draw the
bbox as an approximation). The number of sides drawn in a circle (for CIF
paths) depnds on how large it is on the screen. Also, cells that contain
only small objects may be clipped entirely. The shapes are sorted by
bounding box size so that once I find a shape that is too small to draw I
skip iterating over the rest of them.

I use OpenGL and GLUT for the interface. Transformations are partially
supported in hardware (with good video cards), but I wrote special
transformation code that is optimized for the common 90/180/270 rotations,
etc. that I use for bounding box calculations and other non-drawing
operations. Actually only a 2x3 matrix is necessary since the "w" component
is always 1 and the "z" value is only used for depth sorting of layers and
therefore is never transformed.

Another trick is that panning/translation can be performed through
translation of the frame buffer, and buffer copies are usually done in
hardware in under 1ms. Also, I store pointers to the first shape in each
layer of each cell so that I can iterate over select layers only.

For layouts less than about 500MB-1GB (or around 50% of the free memory) the
read time is limited by the hard drive transfer rate (with a two pass
algorithm), so ~80% of the time is spend in the block freads. Larger layouts
don't fit in memory so the load time is much longer, but the display time is
the same assuming the current visible portion of the layout can fit in main
memory and the user doesn't pan around too much. I'm working on methods of
further compressing the geometry so that larger layouts fit in memory.

I would appreciate any additional feedback you can give me on specific
speedup methods. I would also like to make a full editor out of this
eventually.

Frank