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.
Maybe you are trying a case which needs a library path? I tested with a plain case where the child cells are next to the main one. If your child cells are stored somewhere else and your case needs a library path, the situation may be different.
Hi Matthias, Everything is in the local directory, so that is not the issue... Matt…
On Tue, Dec 22, 2020 at 11:51 AM Matthias Köfferlein < ***@***.***> wrote: Hi Matt, Maybe you are trying a case which needs a library path? I tested with a plain case where the child cells are next to the main one. If your child cells are stored somewhere else and your case needs a library path, the situation may be different. Best regards, Matthias — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#429 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC67SL5PFXNNBLWKVJ4VINLSWD2FHANCNFSM4JQWRVEQ> .
-- Matthew Guthaus Associate Dean of Graduate Studies Professor, Computer Science & Engineering Baskin School of Engineering University of California Santa Cruz https://www.soe.ucsc.edu/people/mrg
I'm attaching a simple test case to narrow it down a bit... pinv.mag has several subcells
but they are all present in that directory.
Thanks for the testcase. It's really very simple.
I could not see the issue on Ubuntu 20, neither with the 0.26.2 which comes with Ubuntu, nor with master :(
The logic of resolving the paths isn't trivial though. I'll check if there is a glitch maybe.
I could finally reproduce and fix it (#693). It will go into master as soon as the CI is done.
As a quick workaround it's sufficient to specify a path along with the file you want to load, i.e. instead of using "klayout pinv.mag" you just use "klayout ./pinv.mag".