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

[klayoutmatthias]

No description provided.

[klayoutmatthias]

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.

Integration

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 ..."

Lambda

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

Comments

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.

[mguthaus]

When opening from the command line, it does not recursively open the subcells. It does work when using File->Open. I'm not sure if this is an intended behavior or whether it can be fixed.

[klayoutmatthias]

@mguthaus Thanks for reporting this. That is not intended - I have created a ticket for this: #693

[klayoutmatthias]

@mguthaus I could reproduce it with older versions, but on 0.26.9 the problem seems to be fixed. Can you confirm this?

Thanks,

Matthias

[mguthaus]

Hi Matthias,

I was using the source from git. I just updated to the most recent commit and it still does it:
ca1ec35

[klayoutmatthias]

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

[mguthaus]

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

[mguthaus]

I'm attaching a simple test case to narrow it down a bit... pinv.mag has several subcells
pinv_test.zip
It shows this as the output:

Warning: Unable to find a layout file for cell - skipping this cell: contact_13
Warning: Unable to find a layout file for cell - skipping this cell: contact_12
Warning: Unable to find a layout file for cell - skipping this cell: contact_11
Warning: Unable to find a layout file for cell - skipping this cell: nmos_m1_w0_800_sm1_dm1_da_p
Warning: Unable to find a layout file for cell - skipping this cell: pmos_m1_w1_600_sm1_dm1_da_p

but they are all present in that directory.

[klayoutmatthias]

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.

Thanks,

Matthias

[klayoutmatthias]

Hi Matt,

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".

Thanks,

Matthias