It looks like you're new here. If you want to get involved, click one of these buttons!
Hi Mattias,
Is there a way to define default layer properties file without specific file name?
I thinking about situation when we will have one .lyp file in the same directory as opening gds file and this .lyp file should be automatically loaded.
I was trying different combinations of special signs and .lyp extension (.lyp, "".lyp, "".lyp, .lyp etc.), but none of them work.
I don't want to have fixed name, as it can change in the different directories.
Do you think that it is possible?
Lidia
Comments
If you have set up a "Technology" then the name /
path for the .lyp is one of the entries in the forms.
Technology choice is "sticky" so should autoload
until you change technologies or somehow lose
the remembered settings.
You could script such a feature in KLayout, but it's probably easier to create a shell wrapper like this simplified one:
For a useful script you should at least add some error handling and sanity checks.
Matthias
Thanks you both for response.
I working on Windows, so this doesn't work for me.
I was able to write basic Ruby script which adds lyp_import tab to the main window (in the Toolbar section).
You need to click on it to load the lyp file (I also set this macro to run on start, so this tab is automatically added). Maybe it will be useful for someone else too (if there is more than one .lyp file the last one (sorted by name should be loaded).
Here is the code:
Thanks,
Lidia
@Lidia Very good! Thanks a lot for sharing this code!
Kind regards,
Matthias
Hello,
I like this concept and extended it a bit:
1) when there is only 1 lyp file in the layout directory, it will be loaded.
2) when there are multiple lyp files in the layout directory, and one has the same name as the layout file, it will be loaded.
3) else, you will be asked to select the lyp file you want.
The script will appear in the "File" menu before "Close".
Cheers,
Tomas
This is definitely a useful feature.
However, in many cases, especially for the latest technologies, foundry PDKs change frequently, and maintaining lip file, to track all the changes, is not the best way, and puts more load and stress on CAD group.
It would be much nicer if Klayout would read (and convert to lip format, if necessary) standard files for layer definition - layermap (some popular foundries), layerprop (Calibre), Virtuoso files (tf, drf), GDS stream out file, etc.
Often, these files (except for GDS stream out) are located somewhere in the PDK directory hierarchy, so giving a pointer to that PDK would be the best way to integrate Klayout into an existing design environment.
In my experience (plenty, but largely trailing-edge) the layers don't
change much (or at all) even when there's a lot of PDK "churn".
I believe there's some facility for importing Cadence PDKs already
(how completely, do not know, but believe the layers get done for
sure).
Just install package "tf_import 1.0" via Tools > Manage Packages...
Most of the IC designers and layout engineers have no clue where tf and dry files are located - and they do not need to know that.
Think about the end users, not about developers - that will make an EDA tool user-friendly.
People working with 2-3 metal stacks will never understand people working with 20 metal layers, with lots of sublayers, derived layers - the total number reach several hundreds, and change from node to node, in the leading edge.
Max, have a look at Tools > Manage Technologies... You can create one for the end users to use...
It's actually quite simple to write converters. CAD people are used to providing the same views for different tools which by design try to be incompatible with each other and specifically the competitor's tool. I don't think it's a big effort to support another view.
Please note that .lyp is eventually much more powerful even than Cadence display files. Taking some weak format as the common denominator would eventually mean to skip some nice features. Take .lyp as an offer. If you want .lyp from your foundry, maybe it's worth asking them to support KLayout. Most foundries are very active KLayout users themselves.
@Max I'd also like to point out a few things about yours and similar requests:
And yes, I'm working with technologies with hundreds of layers. We are using Cadence tech files we have converted once with the mentioned package and distributed. That's a minimum effort and layout people love seeing the same colors and stipples in GDS and Virtuoso.
Matthias
Totally agree: there's no match for KLayout's .lyp format and Layer Window features... Take some time to look a bit deeper into it, it's worth it...
I have been using Klayout over the last 15 years, on a daily basis, and I absolutely love it.
It is the only FOSS tool that is on par and often by far exceeding commercial tools in the same category.
This is simply insane, unheard of.
That being said - I am working in the area of commercial EDA, and I view all this from the viewpoint of expanding the users base for Klayout (both companies and engineers).
There are established ways of doing things in IC design industry - PDKs, files, formats, flows, etc.
It will be much easier for the end users in the industry to adopt Klayout if it would be more easily integrated to the deign environment.
The PDKs change often, file changes and to track all these changes, to update lyp and other files, is too much work for CAD groups.
I understand very well Matthias' point on the lack of publicly available formats and specs, on lack of examples, and on the proprietary nature of many file formats.
I personally think the this is one of the reasons for EDA stagnation.
My viewpoint, when I am promoting Klayout to the design community, is to minimize their headache, their work on integration, to let them use their existing infrastructure as much as possible. Loading standard files describing layers (see above) is not a big deal, I am already doing it, but it would be nice to see such a support built in the Klayout natively.
Many analog designers and layout engineers use a design environment running on Linux (from Cadence, Synopsys, Mentor, etc.) - but many of them do not know what Linux terminal is, how to run Linux commands, what Linux command is, etc.
I agree that writing files in proprietary formats may be prohibited by legal clauses, bit reading them in plain text format, should be much less restrictive.
To me the "Manage Technologies" and dependents, are the PDK more or
less, only "disaggregated", more of a list of pointers and settings.
I could see some value to making a flat-file image from a golden
technology-settings, built into the technology manager tool - such that
a remote installation could just "load and stick" one file and get all set
up the same as the source machine.
Getting libraries, rules and such is another face of the problem. A do-all
technology I/O capability that could bundle, and extract intelligently,
would be cool.