In order to display or otherwise work with a GDSII file, QISLIB must first scan it to determine the contents -- cells, references, entities and so on. It then makes a second pass and loads into memory a quad tree which divides the layout into regions and contains pointers to entity data in the actual file. The entities may remain on disk or be loaded into RAM (depending on whether there is enough RAM to hold the entities.) This scanning of the file and building the quad tree and associated pointers can take a significant amount of time for large files.
If one opens the same file over and over again (in different sessions) the scan/load time becomes a significant overhead. The overhead can be eliminated by producing a memory map -- essentially a copy of what QisMLib places into memory upon scanning/loading a file.
Fig. 1 - when opening a GDSII file, significant computation must be performed. However it is possible to save the results of those computations to a "memory map" for use later.
Once the memory map has been produced (and saved to disk) the next time the user wishes to display or otherwise process the GDSII layout, the memory map is loaded directly -- no need for any scanning of the input file or any building of the quad trees. The time required is really only limited by the disk IO read time.
Fig. 2 - using a memory map for loading greatly decreases the load time since there are fewer computations to do.
In the illustrations above, we produced only the scan map and load map. All of the entity data (i.e. the boundaries, paths, text ) contained in the cell definitions is not put into the memory map. Why? Well if the GDSII entity data is so large it won't fit into the computer's memory then it is left on disk and when loading/processing the file, the entity data is read directly from the source GDSII file.
While this is slower than if the entity data is stored in RAM, it does allow the library to handle very large files.
If you know that your computer has sufficient RAM to store the entity map in memory (and it is compressed as it is read into memory) then you can choose to include this data as part of your dbload file.
First, when producing the memory map use the option to include the entity data.
Fig. 3 - Producing a memory map with entity data.
Fig. 4 - Reading a memory map with entity data.
Memory maps can only be produced for GDSII stream files -- not for OASIS files. The reasons for this are complex and related to how we organize OASIS data vs GDSII data. So the following instructions apply solely to GDSII input.
(1) Command Line
gds2dbload +gds:<GDSII-INPUT> +outdir:<OUTPUT-DIR> [OPTIONS]
where
gds:<GDSII-INPUT> Specify the path of a valid GDSII file to be used
as a source for the .dbload [REQD]
outdir:<OUTPUT-DIR> Specify the path of an existing directory with
write permissions where the .scan.l64 and
.dbload.l64 files will be created [REQD]
The output file name format is
<GDSII-FILE-NAME>.scan.l64
and <GDSII-FILE-NAME>.dbload.l64.
eg a GDSII file demo.gds will be converted as
demo.gds.scan.l64 and demo.gds.dbload.l64
These .l64 file names should not be modified and
should be present in the same directory at all
times.
The version of the .dbload file is same as the
major.minor version of gds2dbload.
E.g gds2dbload v1.6.xx will create
.dbload.l64 v1.06
OPTIONS
-layers:<LAYER-LIST> Specify a list of layer(s) or layer:datatype(s)
to extract. If not used (by default), all the
layers present in the GDSII file will be
extracted as-is.
If the :datatype is omitted for a layer, all
datatypes for that layer are extracted.
eg : -layers:1,2:10,3,4:20 will extract all
datatypes for layers 1 and 3 and only datatypes
10 and 20 for layers 2 and 4 respectively.
Data on all other layers and datatypes will
be dropped
-notext If specified, no text elements are extracted.
[DEFAULT] text is extracted as-is.
-igntxtscal If specified, text scale information will not
be used to compute cell extents. Any cell
containing only TEXT will have zero extents
and therefore it will be considered empty.
-loademptyrefs If specified, empty cells (cells with zero
extents) are loaded.
-log:<LOG-FILE> Create an execution log at the specified path
(including file name.)
The directory component of the path must exist
with suitable write permissions.
[DEFAULT] no log is created.
-OR-
-log+:<LOG-FILE> If -log+ is used, an exisiting file at that path
will be appended. With -log, an exisiting file will be
overwritten.
-silent If used, no messages are written to stdout/stderr.
If not used [DEFAULT], the execution log is
written to stdout and error/warning messages
are written to stderr.
(2) Using the QisMFile Class: QisMFileMemoryMaps
virtual bool SaveAs_memory_maps(const char* outputDir, QisMNotify* progressCb)=0;
where
outputDir Path of the directory where the memory maps
will be created (If NULL or empty, they will
be created in the same location as the input
file)
progressCb Address of a handler for receiving progress
updates.
RETURNS
true Success
false Failure
If false, Call Get_last_error_msg or
Get_last_error_code to get information
about this error.
NOTES
If the source file was loaded to memory i.e.
(QisMFileLoadCtrl::Get_file_data_on_disk() == false),
.scan and .dbload memory maps will be created.
Otherwise, .scan and .load memory maps will
be created.
Pre-load settings such as layer-mapping/filtering
(QisMFileLoadCtrl::Set_layer_map)or dropping texts
(QisMFileLoadCtrl::Ignore_texts() == true)
will be reflected in the newly created memory
maps.
This method is intended primarily for created
.scan/.dbload memory maps since they can be used
independently of the original source file ,