It seems that no matter how much memory we equip our workstation with, we will need to open and display a GDSII or OASIS file that exceeds our available RAM. This application note attempts to describe how the user can set a couple of parameters that affect memory usage and the consequences on loading time and display performance.
To appreciate how to tweak the load parameters, we need to understand how Qckvu3 uses memory to display the layout file. There are actually three critical steps:
Scanning The File - the entire file is scanned and a database of the cells, cell extents and hierarchy is built and stored in memory. The speed at which this happens is often limited by file I/O (which can actually be affected by how much memory your system is equipped with), and CPU speed. This is a single CPU process and does not benefit from multiple CPUs.
Loading the File - what we call loading is more complicated. During this phase, Qckvu3 builds a quad tree which is a sophisticated way of organizing things by where they are located. Because GDSII/OASIS is hierarchical, one does not use a simple quad tree, but rather a large array of quad trees. The building of a quad tree does not re-organize the GDSII file itself - rather a bunch of pointers are created that tell the program where to find an entity or cell based on where it is located. The quad tree is always loaded into memory.
How large the quad tree will be depends not only on the number of entities to be sorted but also on how "fine" a sort we want. The "finer" the sort the faster we can get to things (at least those in a small region) but the more memory the quad tree will occupy. Therefore one of the loading parameters the user can adjust is the granularity of the sort.
Copying GDSII into memory - this is actually optional. If you have enough RAM, you definitely want to copy the GDSII data into memory since accessing it for display purposes will be very fast. To conserve memory we don't make an exact copy - we represent each boundary more efficiently than GDSII does. This means that a 10GB GDSII file might only take 1.5GB in memory.
There are two parameters the user can adjust to control the amount of RAM used.
QIS_QT_NUMPERQ - this parameter is the number of items per quad (where a quad is small subdivision of the layout area.) The default value is 32 - however setting it higher will produce a smaller quad tree needing less space in RAM. Currently this is set via an environment parameter.
Load File into Memory - this is a on/off switch that appears in the Open File Dialog. If checked, the GDSII file is loaded into memory. This eats up RAM but also results in much faster display operation.
Here are two examples used on a pair of Dual-Core AMD Opteron Processors 2.6GHz, running RHEL5, equipped with 32GB RAM.
| Items per Quad |
Load GDSII to Memory? |
Scan Time (mm:ss) |
Load Time (mm:ss) |
Total S+L (mm:ss) |
Home Display (mm:ss) |
Zoom Tight Display (mm:ss) |
Total Memory GBytes |
| 32 | Yes | 4:20 | 5:38 | 9:58 | 0:03 | 0:02 | 3.9 |
| Items per Quad |
Load GDSII to Memory? |
Scan Time (mm:ss) |
Load Time (mm:ss) |
Total S+L (mm:ss) |
Home Display (mm:ss) |
Zoom Tight Display (mm:ss) |
Total Memory GBytes |
| 32 | Yes | 0:26 | 0:25 | 0:51 | 0:02 | 0.00 | 0.7 |