|
How did Artwork get a 10X improvement in GDSVU's display speed? While profiling GDSVU's
behavior we noted that for large complex files, where the entire database is stored in RAM, the time required to render each polygon and pump it through the display channel was the main performance bottlneck. One could attempt to optimize the rendering algorithms; but the existing routines are already good, so substantial improvement is difficult. Instead we took an approach that enables the computer to do less work while still displaying the same amount of useful information to the user. We found a way to do a simple fast computation to replace a complex slow one reducing the net display time. We take advantage of the fact that when the user is zoomed out most of the polygons in the IC are not visible because they are too small.
Consider a IC that is 0.3 x 0.3 inches displayed on a screen 1000 pixels x 1000 pixels. We'll define this as magnification = 1. A single pixel spans a distance of:
There are lots of polygons in a typical IC that are smaller than 38 x 38 um; if we could find a way to filter them then out before rendering we could throw the remaining ones on the screen much faster. Of course, if we have to calculate the size of each polygon on-the-fly we'll end up doing as much work or more than if we render them all. The trick is to do a quick and dirty polygon size calculation just once - when we intially load the file. We then attach a size to the polygon's entry in our internal database. This does take some time but need be done only once while loading; some of the the I/O delays mask the additional processing time anyway. Just before the rendering routine GDSVU checks each polygon's dimension against a preset threshold. If the polygon is too small it's discarded immediately. The check is a very fast go/no-go computation.
What Happens When I Zoom In?"Aha!" you say. "That's very good at Mag=1 but what happens when I zoom in 100X to examine a small portion of the chip. What happens to your trick then when the polygons you would otherwise discard are usable?"Well, a second force helps out at 100X. The deeper you zoom in the less of the chip falls inside the viewing window. A fast clipping routine can eliminate the large percent of polygons that don't cross the viewing window. At 100X magnification roughly 90-95 percent of the polygons don't need to be rendered. You can remove these before the pixel threshold test. Bottom Line - At low magnification the "pixel threshold filter" removes polygons that are too small to see. At high magnification the "window clipping" filter deletes polygons that don't cross the window. At medium magnifications both filters reduce the total number of polygons the display needs to deal with.
|
|
|
User ControlsRather than select a hardwired pixel threshold we made it a configurable parameter. You have a preference setting dialog that enables you to set a pixel threshold from 1-20. |
Structure Extent OutlineDuring our initial tests we ran across a few GDSII databases that completely "disappeared" when viewed full size. This was most disconcerting to the user and we had to figure out a way to prevent this (and the resulting call to technical support...). We added an option we call: Display Structure Extent Boxes. When this option is turned on we draw a simple box around the extents of all of the structures that are inserted one level down from the current structure's hierarchy. This makes it easier to navigate around when most of the polygons in your file are filtered out. |
|
Artwork Conversion Software, Inc. [Company Profile] 417 Ingalls St. Santa Cruz, CA 95060 Tel (831) 426-6163 email:info@artwork.com |