Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature request: support Magic file format (*.mag) #429
Here are some Magic specific implementation details:
Magic doesn't follow the "one file, one layout" concept of other stream formats
In the implementation, KLayout will use the given file to derive the location of the cell files. On reading, if will read the given file and then try to read further files as they are required for child cells. This continues recursively.
To locate files for child cells, library search paths can provided (see Reader Options). These paths specify search locations for cell files. Relative paths there are resolved relative to the original file. The library search path is specified in the Reader Options. Expression interpolation is supported for these paths. Specifically these dynamic variables can be used:
This scheme allows embedding Magic libraries into KLayout technology folders by using
Upon write, the child cells will be written to individual ".mag" files in the location given by the original output file. If the output file's name does not correspond to a cell, KLayout will write a virtual top-level ".mag" file containing references to all cells present in the layout.
The MAG format reader and writer is integrated into KLayout in the same way than the other formats.
The "LoadLayoutOptions" and "SaveLayoutOptions" objects have been enhanced by several attributes specific for MAG files.
The strm2x tools from the "buddies" collection are enhanced by some MAG specific input options. There is also a "strm2mag" command line tool for converting any supported format to MAG.
Layer names are an essential ingredient for Magic, so proper layer mapping is important. Specifically when using numbered formats such as GDS or OASIS a layer mapping table needs to be supplied.
For example for "strm2mag" use the "-im" option to supply such a mapping:
Magic uses the concept of "lambda" while GDS and most of the other formats are physical formats requiring physical dimensions.
Hence, KLayout needs the lambda value for reading. Conversely it also needs a lambda value for writing.
On reading, the layout coordinates are multiplied with the lambda value to obtain the physical coordinates. On writing, all coordinates are rounded to lambda and written to the "*.mag" layout files. Care must be taken to avoid rounding errors here: if the original layout isn't on-grid with lambda, the resulting layout will be distorted. So conversion from GDS or other formats back to MAG format is safe only under the condition of compliance with the lambda rule.
There is a basic conflict with the way KLayout handles technologies and Magic does: in KLayout, a technology is set and layouts are read into this technology. In Magic, the technology is defined inside the file.
To solve this problem, KLayout reads MAG files with the proposed technology. After reading them, it will attach the resulting layout to the technology given inside the first MAG file, provided that
KLayout's MAG reader supports fractional coordinates (floating-point numbers). This basically allows deviating from the fixed grid of "lambda". However, such coordinates are not supported by Magic.
The same is true for generic transformations - KLayout basically supports transformations matrices that represent scaling and arbitrary angle rotations. Shearing is not supported. The transformation matrix members can be floating-point numbers.
KLayout assumes UTF-8 encoding for Magic files.
Quoting and backslash escaping of cell names, layer names and label texts is basically supported by KLayout, but not by Magic.