I noticed that on latest versions (i tried on 0.30.5), markers frames always show when adding a marker to LayoutView (0.28.5 does not do that).
Is there a way to turn off marker frames?
I also tried to set the frame color to be the same as the background color but it sets both the marker and the frame.

Thanks!

def addTextMarker(self,layoutView, x,y,string,color):
  m = pya.Marker(layoutView)
  bgColor = pya.QColor(layoutView.get_config("background-color"))
  m.color = color.red*65536 + color.green*256 + color.blue
  m.frame_color = bgColor.red*65536 + bgColor.green*256 + bgColor.blue      
  m.set_text(pya.DText(string,pya.DTrans(pya.DPoint(x,y))))   
  m.line_width = 10

I tried HW-klayout-0.29.11-macOS-Sonoma-1-qt5MP-RsysPhb311.dmg but this doesn't open - it only crashes when run (crash report window appears)

Next I tried ST-klayout-0.29.11-macOS-Ventura-1-qt5MP-RsysPsys.dmg but nothing happens when I try to open this version of Klayout.

There are a vast number of *dmg files to pick from. I have no idea what would run on my laptop.

I do see the different layers (.lyp) and I'm able to run a DRC rule check (.lydrc).The PDK includes .lyp, .yaml, .lydrc, .lyt and .oas files, and was provided mainly to use with GDSFactory.

Did something went wrong during the importation of the PDK into KLayout? Or could it be that the foundry does not allow us to acess the PCell properties? Are there any other ways to edit the PCell parameters besides manually modifying the lengths of the polygons?

PS. I am new to photonics, and would appreciate any help!

I have created few years ago some xsection files, and I used them on klayout 0.25.

Now I'm trying to use the same files on klayout 0.29.0 but I received this error message:

**TypeError: no implicit conversion of RBA::Vector into Integer for argument #1 ('left') for argument #1 ('box') in Polygon::initialize
**
There is the possibility to convert the xsection from an old version to a new one?

Thanks and regards

Luciano

My Environment:
KLayout Version: [ -- 0.29.9 -- ]
PDK: SkyWater SKY130
The Main Problem:
No matter which design I use, the LVS comparison fails with a "Netlists don't match" result.
Here's what I have tried:
1. Custom Designs: I started with my own custom GDS files (both a simple PMOS and a transmission gate) and their corresponding SPICE netlists. They all failed.
2. Official PDK Standard Cell: To rule out errors in my own files, I used a known-good standard cell from the PDK (sky130_fd_sc_hs__and2_1.gds and its .sp netlist). This also failed with the same error.
3. Using the Extracted Netlist as a Reference: This is the most confusing part. I first ran LVS to generate an extracted netlist from the GDS file. Then, I ran LVS a second time, using this newly extracted netlist as the reference schematic. Logically, this should always pass, but it still fails with "Netlists don't match".

This last test makes me think the issue is not with the GDS or SPICE files themselves, but with my KLayout command or environment setup. It seems the comparison step is fundamentally broken for some reason.

My Question:
Why would an LVS check fail when comparing an extracted netlist against itself? What could cause this behavior? Is there a common setup mistake or a required -rd parameter for Sky130 LVS that I might be missing?

I run these commands in the klayout_sky130/lvs/ folder
python3 run_lvs.py --design="/home/OpenFASOC/openfasoc/generators/glayout/output/pmos_sky130.gds" --net="/home/OpenFASOC/openfasoc/generators/glayout/output/pmos_sky130.sp" --thr=16 --set_verbose --set_spice_comments

python3 run_lvs.py --design="/home/OpenFASOC/openfasoc/generators/glayout/output/transmission_gate_sky130.gds" --net="/home/OpenFASOC/openfasoc/generators/glayout/output/transmission_gate_sky130.sp" --thr=16 --set_verbose --set_spice_comments --lvs_sub="VSS"

python3 run_lvs.py --design="/home/OpenFASOC/openfasoc/generators/glayout/output/sky130_fd_sc_hs__and2_1.gds" --net="/home/OpenFASOC/openfasoc/generators/glayout/output/sky130_fd_sc_hs__and2_1.sp" --thr=16 --set_verbose --set_spice_comments --lvs_sub="VNB"

I have attached a zip file ([--klayout_lvs_debug.zip--]) containing the GDS, SPICE files, LVS rule deck and results, and the Python script I'm using to run the command.

Any help would be greatly appreciated. Thank you!

When running DRC on large & complex layouts, I often run into an issue of hanging/crashing. This seems to be particularly present when there are many instances of waveguide structures and rules such as separation, space, or width are attempting to be checked.
My local machine has 65GB ram & an 8 core processor.

I have these DRC commands (where layer and o_l are defined as layer inputs, value is a number, and rule & description are strings):
o_l.sep(layer, value).output(rule, description)
layer.width(value, angle_limit(45.degree)).output(rule, description)
layer.space(value) .output(rule, description)

And the behavior is that it slows my computer down, consuming all the memory, until KLayout becomes unresponsive for quite a while until eventually crashing. This behavior is also present when I implement tiling.

I am wondering what you suggest doing to be able to successfully run these kinds of DRC rules on layouts such as this with many structures present.

Thanks!

On both systems the setting is available within the Setup > Application > Customize Menu settings under Main Menu > zoom_menu.prev_display_state titled Back and similar for Forward; however, setting this has no effect for me on either system. In Linux I am able to change the '@toolbar.prev_display_state' and '@toolbar.next_display_state' entries within the klayoutrc and these work, but this change does not work for me in Windows 11. Within the klayoutrc file these settings within the zoom_menu have no effect on either system, even when I set them to conflict with the above ​toolbar settings. Please advise.

Thanks!

After fabrication, we found that this section of the waveguide exhibits unexpected reflection. Our current analysis suggests that this horizontal line may have a physical meaning in the stepper lithography process—namely, that when reaching a boundary, the stepper turns off the light source.

Therefore, I would like to know how such zero-distance horizontal lines are generated in KLayout, what their actual significance is, and how they can be eliminated? Thank you.

I'm attempting to implement a PCell library which references itself to construct more complex PCells. In order to do that I need to populate the library without destroying it and rebuilding it since it would cause to unlink all existing PCells.

I achieved to do that by creating the library and using the Library reference instead of using the "self", but the library entries don't automatically refresh like it does when executing the regular self.register(xx).
I tried using self.refresh(), lib.register(xx) again, lib.refresh(), updating the QWidget associated with the libraries, and there's no "library.unregister()" function to try (actually nor "layout.unregister_pcell()" but there is "remove_technology". I guess library.delete() would be the equivalent).
The only solution I found was to switch the selected library view to the "Basic" one and then back.

Here's a sample:

import pya, os
import importlib.util as ilib

lv = pya.Application.instance().main_window().current_view()
wid = lv.widget()
widLib = lv.widget().libraries_frame()

def ezimport(filePath):
  # Makes it less verbose to import modules found from the executing fileName
  # → Script executed from a technology
  extFilePath = filePath.split("/")
  selfPath = os.path.join(os.path.dirname(__file__),*extFilePath)
  spec = ilib.spec_from_file_location(extFilePath[-1], selfPath)

  md = ilib.module_from_spec(spec)
  spec.loader.exec_module(md)
  return md

ent1 = ezimport("ent1_PCell.py")
ent2 = ezimport("ent2_PCell.py")

class NEW_LIB(pya.Library):

  def __init__(self):

    lib = pya.Library.library_by_name("NEW_LIB")
    if not(lib):
      # Set the description
      self.description = "New Library"
      self.register("NEW_LIB")

    self.lib = pya.Library.library_by_name("NEW_LIB")

    # Create the PCell declarations
    # Register PCells to the already existing NEW_LIB already exists
    self.lib.layout().register_pcell("ENTRY1", ent1.PCell1())
    self.lib.layout().register_pcell("ENTRY2", ent2.PCell2())

    self.lib.register("NEW_LIB") # Only registers internally, won't update the library view
    self.refresh() # Won't do a thing
    lib.refresh() # Won't do a thing

    wid.update() # Won't do a thing
    wid.repaint() # Won't do a thing
    widLib.update() # Won't do a thing
    widLib.repaint() # Won't do a thing

# Instantiate and register the library
NEW_LIB()

Thank you,
Gerard

when we import both file into same libray (3rd file), that will been change to
file3 , cell:OOO and cell:OOO$1
we want to change that as
file3 , cell:OOO and cell:OOO_1

does Klayout have any option to control that ?
or , we just using a scribe to change the cell name?

Wanted to bring to your attention that when a KLayout "tech" folder has the below structure:

tech/
test.lyp -> 2/test.lyp
test.lyt -> 1/test.lyt

It fails to initialize the Layers with the corresponding message:

I understand that KLayout assumes that .lyt and .lyp files should be in the same directory but when this directory is managed by a Design Management Tool it can happen that these files reside in different folders.

I need to set up a DRC check where one layer is inside another, and then one of the outer edges can be closer than the other edge of the corner.
To solve that, I thought on measuring the distance of each corner to the outer edges and only 1 shorter distance is to be allowed per corner.
That requires to measure the distance between corners and edges.

As per docs, corner(as_dots) generate a list of dot_like edges (I guess very short/infinitesimal edges), and primary.separation(secondary,value) can measure the separations between 2 sets of edges.

When assembling everything however, no separation returns an error (error count is 0 always, no matter what value is set):

M1.edges.separation(V1.corners(as_dots),value.um)

The usage of V1.corners(as_dots).raw or V1.raw.corners(as_dots) didn't help either.

I checked for M1.edges.separation(V1.edges,1.um) and it works as expected, so I'm wondering what's the way to measure point to edge distances.

Thank you.

Gerard

I'm testing the different functions available for manipulating polygons. I need one to resize the perimeter of the polygons and "size/sized" would do the trick. In docs it's commented that it would require an EdgeProcessor step to fix self-intersections.
When doing so I discovered a weird behavior involving polygon type conversion and resizing magnitude. Here's a tested script:

ly = pya.Application.instance().main_window().current_view().active_cellview().layout()
c = ly.top_cell()

c.clear_shapes()

if c == None:
  raise Exception("No valid top cell")

l1 = pya.LayerInfo(1,0)
l2 = pya.LayerInfo(2,0)
l3 = pya.LayerInfo(3,0)
l4 = pya.LayerInfo(4,0)

poly = pya.DPolygon([
  pya.DPoint(-0.4,-0.45),
  pya.DPoint(-0.4, 0.45),
  pya.DPoint( 0.4, 0.45),
  pya.DPoint( 0.4,-0.45)
])

# First size then convert

polySmall1 = pya.EdgeProcessor().simple_merge_p2p([ poly.sized(-0.06, -0.06).to_itype(0.001) ], False, False, 1)[0].to_dtype(0.001)
polyMid1   = pya.EdgeProcessor().simple_merge_p2p([ poly.sized(-0.21, -0.21).to_itype(0.001) ], False, False, 1)[0].to_dtype(0.001)
polyBig1   = pya.EdgeProcessor().simple_merge_p2p([ poly.sized(-0.22, -0.22).to_itype(0.001) ], False, False, 1)[0].to_dtype(0.001)

# First convert then size

polySmall2 = pya.EdgeProcessor().simple_merge_p2p([ poly.to_itype( 0.001 ).sized(-60,   -60) ], False, False, 1)[0].to_dtype(0.001)
polyMid2   = pya.EdgeProcessor().simple_merge_p2p([ poly.to_itype( 0.001 ).sized(-210, -210) ], False, False, 1)[0].to_dtype(0.001)
polyBig2   = pya.EdgeProcessor().simple_merge_p2p([ poly.to_itype( 0.001 ).sized(-220, -220) ], False, False, 1)[0].to_dtype(0.001)

#####################

# Base shape
c.shapes(l1).insert(poly)

# Small resizing is consistent
c.shapes(l2).insert(polySmall1)
c.shapes(l2).insert(polySmall2)

# Mid resizing is still consistent
c.shapes(l3).insert(polyMid1)
c.shapes(l3).insert(polyMid2)

# Big resizing is inconsistent: polyBig1 behavior is expected, polyBig2 returns a corner rectangle
c.shapes(l4).insert(polyBig1)
c.shapes(l4).insert(polyBig2)

I wanted to ask what's the correct approach to always get the expected result and have no surprises down the line (I'm guessing one is to always use Polygon instead of DPolygon).

Thank you,

Gerard

I've been trying to set up a script or workflow that would allow me to extract the netlist of a big (2GB layout) and check for shorts or opens.

"Trace All Nets → Flat" + "netlist browser" works wonderfully, but as mentioned in other places I read, it doesn't allow for filtering of cells to hide dummys.
Ideally, this process would also be nice to have it programatically, hence the use of DRC or using the "pya" API.
I found that any method I used it had some drawback that other ways don't, and viceversa:

"pya" I think would be best as it can import other functionalities seamlessly, and I'm most familiar with python syntax.

Btw:

• Is there a way to load the "pya netlist" to the "netlist browser" after execute_netlist so no manual opening is needed, like netlist does in "DRC"?
• Is there a way to load the connectivity of an existing technology to the LayoutToNetlist? I can't find the method to load the pya.Technology().technology_by_name("technology_name").component("connectivity") directly, and I'm currently forced to hardcode it or perform an inconvenient "for loop" for each connect()

Thanks!

Gerard

I see in previous comments that you've stopped working on the XSection portion, but in it's current implementation, are there any options to define functions (process blocks) within the xsection script? Or would I have to build my own XSection with modifications to allow for process blocks and/or loops of process steps?

Thank you!

I would like to ask your support on a callbacks-related issue.
Currently using KLayout 0.29.12

The flows I raise my concern about are:
1. The instantiation of a PyCell.
2. The update of it's parameter set.

More specifically, when instantiating a PyCell, I get multiple redundant triggers of the callbacks some for empty string and others for None values. Filtering None values was easy but i can't filter empty string values as no callback would trigger upon instantiation.

Opening the Object properties widget also triggers one unnecessary callback, each time I open the window.

Lastly, updating the PyCell's parameter set again triggers the callbacks multiple redundant times.

If there is anything more that you require from me to further explain the issue let me know.

Kind Regards,
Chris

I try to export cells information with fixed names to csv file using search and replace function.
I have several questions?
1): it shows cells information, but only in hierarchy, how to get them in flat?
2):the csv file have some information, but I only need xy points, how to get them without reprocessing data？

Best regards!
Weiling

I built version 30.2 from source on Rocky Linux 8, using python 3.12. For both the skywater and gf180mcu PDKs, I get error messages that make it look like there are incompatibilities between the PDKs and the Python packages kfactory and/or gdsfactory. I get error messages for most pcells when I try to instantiate them. I installed the salt packages for both in klayout. What is going on here? Examples are below. Thanks. --Curt.

Like for skywater, when instantiating pcell "nfet":
ERROR: AttributeError: module 'kfactory.kcell' has no attribute '_get_default_kcl' in PCellDeclaration.produce
/home/cate/Downloads/klayout/salt/Efabless_sky130/tech/sky130/python/cells/pdk.py:32
/home/cate/Downloads/klayout/salt/Efabless_sky130/tech/sky130/python/cells/draw_fet.py:550
/home/cate/Downloads/klayout/salt/Efabless_sky130/tech/sky130/python/cells/fet.py:261
/home/cate/Downloads/klayout/bin-release/pymod/klayout/db/pcell_declaration_helper.py:274

or for gf180mcu, when instantiating "cap_pmos"
ERROR: TypeError: 'builtin_function_or_method' object is not subscriptable in PCellDeclaration.produce
/home/cate/Downloads/klayout/salt/gf180mcu/pymacros/cells/draw_cap_mos.py:62
/home/cate/.local/lib/python3.12/site-packages/kfactory/decorators.py:383
/home/cate/.local/lib/python3.12/site-packages/cachetools/_cached.py:173
/home/cate/.local/lib/python3.12/site-packages/kfactory/decorators.py:432
/home/cate/.local/lib/python3.12/site-packages/kfactory/decorators.py:458
/home/cate/.local/lib/python3.12/site-packages/kfactory/layout.py:1003
/home/cate/Downloads/klayout/salt/gf180mcu/pymacros/cells/draw_cap_mos.py:193
/home/cate/Downloads/klayout/salt/gf180mcu/pymacros/cells/cap_mos.py:182
/home/cate/Downloads/klayout/bin-release/pymod/klayout/db/pcell_declaration_helper.py:274

nwell = input (1,0)
cellBulk = RBA::CellView::active.cell.bbox
pwell = cellBulk - nwell

But, the last command does not work, because I cannot mix a bbox with a polygon.
Here, I cannot use make_polygon : I need it for the extraction of NMOS in triple well.

Thank you,

Laurent

You can see that the default pop up location always locate at the center of the Xsection, which always happen to be the important location that I want to view. In the script, I'm doing multiple snapshot so that I can check how the Xsection looks at different process steps. But since this popup always block the view, I have to move it away and then click the Yes button so that It can continue. But the next popup will again appear at the center location. Is there away to automatically adjust the popup position to a edge location, so that I can only need to click the YES button without the need to drag this to the edge from the center location?

thank you.

die=input(71,0)
die.data.each do |xx|
puts  xx
end

Klayout DRC will output what the data of layer 71 , 0.
but do you have sort the data before ouptut?

I'm scratching my head over a strange false flag scenario.

I've boiled it down to a very simple shape - a path with 3 points. How I arrived at these points is somewhat convoluted but it is part of a much larger structure that has been giving me trouble with false DRC flags. Here is the shape:

And here are the vertices:

-8763.84300 -11243.48400
-8763.72400 -11243.60500
-8763.60500 -11243.72400

I've attached the simple GDS (with both path and polygon interpretations) and DRC script in the zip file. I'm getting two errors flagged:

1. The leftmost corner is likely being flagged as an acute angle. This sort of makes sense to me if you chalk it up to machine precision. I know you can also filter out angles if needed. Let me know if I'm wrong in that assumption though.
2. The middle of the top right edge is being flagged. This is where I believe the path-to-polygon bug comes into play.

I'll just focus on the second point. When I 'merge shapes' on the path object, I get this jagged tooth where it is flagged.

It makes sense to me why this is flagged, but a) I don't know why this tooth is present in the merged shape, and more confusingly b) why does the error appear to be on a scale larger than the database unit of 1nm (1nm in y but 2nm in x) - similar to the error in (1), I'd expect a rounding error to be at most off by the database grid.

Curious to hear your thoughts on this. I haven't yet looked too far under the hood, but happy to be pointed in the right direction!

Thanks,
Adam

I am using xic for schematic capture and LVS/DRC, which stores the schematic in some gds layers. trying to import the layers in Klayout. I changed the lyp file .. the electrical layers from the xic gds file don't show up and a Klayout write to gds file don't include the electrical layers.

Thank you.