Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: support Magic file format (*.mag) #429

klayoutmatthias opened this issue Nov 22, 2019 · 1 comment

Feature request: support Magic file format (*.mag) #429

klayoutmatthias opened this issue Nov 22, 2019 · 1 comment


Copy link

@klayoutmatthias klayoutmatthias commented Nov 22, 2019

No description provided.


This comment has been minimized.

Copy link
Collaborator Author

@klayoutmatthias klayoutmatthias commented Dec 1, 2019

Here are some Magic specific implementation details:

Multi-file paradigm

Magic doesn't follow the "one file, one layout" concept of other stream formats
Instead, each cell is represented by an individual file. This makes integration with the other readers difficult.

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:

  • $(tech_name): the name of the KLayout technology this file is loaded for (the proposed technology, see "Technology management" below)
  • $(tech_dir): the path to KLayout's technology folder for the proposed technology or "." (relative to the original file) if no such technology is proposed
  • $(magic_tech): the technology name from the MAG file

This scheme allows embedding Magic libraries into KLayout technology folders by using $(tech_dir) as the base path.

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 mapping

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:

strm2mag --magic-lambda-out=0.005 --magic-tech=scmos input.gds converted.mag -im "1/0: nwell 7/0: polysilicon 16/0:metal1 17/0:m1contact 18/0:metal2 ..."


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.

Technology management

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

  • No explicit technology was proposed
  • The technology inside the MAG file is a valid KLayout technology


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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
1 participant
You can’t perform that action at this time.