Areafill makes use of multiple processes to achieve concurrency. When a user launches the AreaFill manager (areafillmgr64) it scans the input file whether it be a GDSII or an OASIS file for layer information and data extents. It then decides how to partition the area to be analysed (usually data extents or user defined window) and in turn launches a number of analysis engines (areafill64) each of which works on a portion of region of interest. Each copy of areafill64 works independently and unaware of the other engines. By default the total number of instances of areafill64 is equal to the number of threadable processes divided by 2, e.g. an octacore processor capable of hyperthreading will result in 8 instances of areafill being launched. The user can control the number of areafill engines to be launched with the -nfork command line option.

Because each instance of areafill64 that gets launches is a complete process unto itself, each instance gets its own copy of the input file. Thus the total resource burden when running the AreaFill Manager is the sum of the resource demands of a single instance of areafill64 multiplied by the number of instances launched.

The implications or this multiplier on memory resources when running analyzing a GDSII file are obvious, usually the memory required to load a GDSII into memory is about 1/3 to 1/2 of the GDSII filesize. So if a GDSII file is 1GB in size, then 8 instances of the areafill64 will require 2.7 to 4 GB of virtual memory.

The story with OASIS files is a little tricker because of the nature of OASIS. OASIS has implicit compression and explicit compression. One of the ways implicit compression is achieved is by making use of modality, e.g. when the layer from one polygon to the next in the OASIS stream does not change, it is not necessary to write it to the OASIS stream. Explicit compression is associated inserting compressed blocks of OASIS data into the OASIS stream. These are known as CBLOCKs. By making use of implicit and explicit compression an OASIS file can achieve 5 to 20 reductions in file size over its GDSII equivalent.

When either the AreaFill manager or an engine opens an OASIS file, CLBOCK data is written to disk as uncompressed OASIS into a .BIN file. Normally the user never sees the .BIN file because it gets cleaned up when the AreaFill manager or engine exits. From the products point of view, the actual size of the OASIS database is the sum of the file size of the OASIS file itself and the accompanying .BIN file. This is significant as the virtual memory (VM) size for each instance of the areafill engine that gets launched is the sum of the .BIN file generated by the tool plus the .OAS (OASIS file size) plus some overhead. This can be significant especially when the .BIN file is several multiples of the input OASIS file.

The total memory needed is the VM for each areafill64 times the value of nfork (-nfork:N command line option). As mentioned above a user can control resource allocation with the -nfork command line option and should do so especially if they observe swapping.

Example Command Line

When using one of our OASIS example files (cblocks.oas) which is 750 MB in size, the .BIN files correspond to 2.0 GB in size, so the VM is expected to be at least 2.75 GB.

areafillmgr64 cblocks.oas out44_4_12_13.txt = +12,13 -tile:1,1 -directional -step:4 -nfork:4 -thrnum:4 -log:out44_4_12_13.log

ryzenx8:antonio: $ ls -trl *.bin
-rw-r--r--. 1 antonio users 1955225791 Mar 13 17:57 acs_oasis_data_10163_1.bin
-rw-r--r--. 1 antonio users 1955225791 Mar 13 17:57 acs_oasis_data_10166_1.bin
-rw-r--r--. 1 antonio users 1955225791 Mar 13 17:57 acs_oasis_data_10171_1.bin
-rw-r--r--. 1 antonio users 1955225791 Mar 13 17:57 acs_oasis_data_10181_1.bin