It looks like you're new here. If you want to get involved, click one of these buttons!
Hi Matthias,
Would it be possible to add a Load/Save option (to/from text file) in the Layer Stack pop-up window "Edit Technology"? This way you can quickly trace nets in the Default technology while switching between different designs without retyping the layer stack each time or setting up a technology for each of them.
Cheers,
Tomas
Comments
Hi Thomas,
the problem occurred to me as well. So rule
#1
of successful software development applies: make the programmer feel the same pain as the users and you will get a premium product.In other words: a solution is in sight. The master branch (soon to come 0.28) will have the ability to define multiple stacks per technology (Technology stacks on the left side). Here: default (always there), STACK1, STACK2 and STACK3. Names can be changed but should be unique.
If you like to try it (feedback welcome): a build for the current master branch can be downloaded here: https://www.klayout.org/downloads/master/
Matthias
Hi Matthias,
I've been using this for a while now and it works great!!! The only hassle (once in a while) is to pass on a (large) layer stack to someone else. The only option, besides re-inserting all the layers manually, is to copy the part from one layoutrc file to the other. Is adding a Load/Save from text file an option for future releases? To avoid loosing all my layer stacks (not happened yet), I also backup my full layoutrc file regularly... ;-)
Cheers,
Tomas
The layer stack info is in a tech lef and the mapping to gds/oasis layer/datatype is defined in a map file.
klayout already reads both file types, it "just" has to "fill out the layer stack form".
Another approach is to "guess" the metal stack by looking for struct that have three layer with two rectangles covering a whole bunch of squares. For this to work reliable one needs some heuristics to filter out struct from ram/rom generators and analog blocks. Doesn't work with gds written by magic, because there are not via struct.
This worked remarkably well for a lot of technologies, but then via holes became rectangles and got different datatypes for different sizes, so it got a little bit trickier.
There are a number of options:
1.) Use a technology. This technology is stored as a .lyt file in
<klayout-home>/tech/<name of tech>
. This folder is a package that can be given to others including companion files such as layer properties files. The layer stack is part of the .lyt file.A technology is the preferred way of wrapping "knowledge" about a process.
2.) To save and load the default technology, use
This file will also contain your default stack, among other settings such as the default layer properties file.
3.) Use a DRC (yes, DRC) script with netlist output. This is equivalent to "Trace all nets", which is often faster than tracing single nets, specifically in hierarchical (deep) mode. Here is an example for Sky130A:
This script option leverages the full power of the DRC language, so you can code all kind of boolean formulas. You could even include device recognition here. A DRC script can be passed to others as a single file or can be embedded inside a technology.
Matthias
Hello Matthias, Stefan,
Thank you for the feedback!
1) I've tried to set up a simple technology as a test and it works fine, but I rarely have 2 layouts with the same technology so I don't bother too much about setting up a technology for each of them (yet).
2) Cool, I created some menu entries for loading and saving the default technology.
3) I'm doing some tests with "Trace all nets", both via the "Tools" menu and DRC scripting, and it works fine.
3a) The test layout has some "floating" shapes, like physical label characters, alignment marks, dummy pads,... Is there a way to exclude these from the generated nets, i.e. skip nets which only have one shape, or by extension less than x shapes?
3b) Is there a way to get the "physical" length of the traces?
Cheers,
Tomas
Hi Thomas,
regarding 3a.): for a real netlist with devices, there is such a way, but not without devices. With devices, nets not attached to a device (except inside black box macros) are eliminated by "Netlist#purge_nets". Without devices, it is hard to tell what is a dummy net and what isn't. The number of shapes is likely not a good criterion. I the cases I have dummy features such as labels of dummy fill tiles are located inside certain cells and I can exclude them by name.
3b.) There is an API to get the shapes of a net, but that's it. Without devices you cannot even say what is the driver and receiver end. That is important as there may be multiple receivers.
Matthias
Hello Matthias,
Thanks for the feedback! Indeed, the number of shapes is not a good idea...
For layouts without devices/netlists/texts/decent hierarchy (that's the kind of gds files I have to deal with ;-) I came up with the following flow:
1) Add texts in the center of specific shapes (typically a wire bond pad/probe pad/bump pad with specific dimensions) on a specific layer (typically the top metallization layer) via script 1.
2) Perform a "Trace All Nets" and save to a .l2n file.
3) Remove all nets without a text added from the .l2n file using script 2.
4) Open the updated .l2n file in the netlist browser
Cheers,
Tomas
Cool image!
Could sell as art.