GATE_SIDES = GATE.edges.not(OXIDE.edges)
violation = NWELL.edges.separation(GATE_SIDES, 1.0.um, projection) 

Implementing via check
apparently klayout does not provide a check for via, in the sense the width is fix for instance 0.26um.

The obvious solution will be to check for size > 0.26 and < 0.26.

via1.drc(width > 0.26).output("VIA1.W.1", "VIA1 width > 0.26") (expected true if via width > 0.26um) failed !
via1.drc(width < 0.26).output("VIA1.W.2", "VIA1 width < 0.26") (expected true if via width < 0.26um) works !
or
via1.drc(width != 0.26).output("VIA1.W.3", "VIA1 width != 0.26") (expected true if via width != 0.26um) failed !

projection, no help
Does width work only for < ?

if yes then there is some problem with these examples

errors = in.drc(width < 0.2.um)
errors = in.drc(width <= 0.2.um)
errors = in.drc(width > 0.2.um)
errors = in.drc(width >= 0.2.um)
errors = in.drc(width == 0.2.um)
errors = in.drc(width != 0.2.um)
errors = in.drc(0.1.um <= width < 0.2.um)

Hope you are doing well,

In the context of gf180, I've been experimenting with DRC, how to make it faster and improve quality of life from a GUI user point of view.
My initial issue was the speed of the DRC deck. For a somewhat simple full chip design, deep DRC, I was getting run times of more than 20 minutes on my beefy computer when starting the DRC from the GUI.
I knew that there should be some way to improve this, because CPU utilization was generally low, albeit with some large spikes. That gave me the feeling that the process was memory-bound instead of cpu bound.
The gf180 pdk (same with IHP) also provides a python utility, where each file was run in its own klayout process. This considerably improves speed (~5x), but suffers from a few issues:
1) Each run generates its own reports, checking for DRC clean is a nightmare
2) General layers have to be recomputed each time. While this does not always result in longer run time depending on number of cores, it is a certain limitation. Moreover, the general layers are duplicated in ram for each process, causing a larger memory usage.

I've experimented a bit and implemented my own DRC approach to try and solve both issues. It is implemented fully in ruby using forks, and has great performance (similar performance as the python script with untapped potential and less RAM usage).

Here are the currently issues preventing it from being merged to upstream PDK

GUI Cancel

Due to something in QT/graphics driver panicking when joining threads in GUI, I have to run the forking script in a klayout batch mode process. This means that (1) the project has to be saved to disk before running DRC, but more importantly that (2) there are currently no way of canceling a DRC run from the GUI.
(2) is because it seems there are no cancel flags exposed from the C++ to ruby API. From my understanding, the cancel action causes the C++ side DRC calculation function to throw an exception, which is caught from ruby. In my case, I do not think I can use this approach in a clean manner.

Report merging and report files

My first issue with drc reports is that there is currently no way of obtaining one without creating a file. That means that in case of parallel DRC runs, I have to create one temporary file per run, which is not so clean. I implemented a basic functionality allowing to get reports as a string rather than a file here, but I don't think it is very good. I then reverted to using files.

My second and bigger issue is that there is no way of merging report files together, so that it is presented cleanly in the GUI report view. In the present case, we only need a simple approach, as we are guaranteed that the top cell of all report files is the same. I've implemented this outside klayout here. Beware, that specific part is mainly AI (goal was proof of concept).

Conclusion

Do you think that this approach to DRC is sane?
How would you see the cancel functionality implemented? Is there some way I did not think of, or new functionality is need on the klayout side?
Same thing with the report file merging. If you guide me a bit (where to implement this function), I could try to make an MR.

Thanks!

I'm using KLayout (version 0.30.1 on Linux) for the DRC.
In photonics, some layers can have complex structures (many curves), and running a DRC on these structures can take many hours (>24 hours), and it is not uncommon that KLayout crashes in the end (because out of memory (>96 GB)).
Therefor, we want to exclude certain areas in a layer from the DRC.
(Even for simple structures, this is necessary because for finding overlaps of polygons within a single layer, it is sometimes allowed to have overlaps at specific locations. In photonics, 2 waveguides in the same layer may sometimes cross each other. So, we want to exclude these areas also from the DRC.)

So, I create a new layer, and place some polygons (the exclusion areas) in it. And I do the DRC check on

layer.not(exclusion_layer)

But this doesn't work, because after the boolean NOT operation, the layer is in 'clean' state, and this causes problems finding the overlaps.

Let me explain this with an example.

The left red cross in the layout are 2 straights (a horizontal and a vertical) in the same layer (layer 1).
I find the overlap with:

layer1 = input(1)
layer1.merged(2).output("Overlap layer1")

This gives the expected overlap.

The right purple 'double' cross in the layout are 2 horizontal straights, and these straights overlap with a vertical straight. These 3 straights are in layer 2. When I run the same check again (without using an exclusion layer), I get 2 overlaps (as expected) Call this the 'top-overlap' and the 'bottom-overlap'.

layer2 = input(2)
layer2.merged(2).output("Overlap layer2")

Now add the exclusion layer (layer 24, green).

exclusion_layer = input(24)

When I run the last overlap test again, I want to find the 'top-overlap', but not the 'bottom-overlap', because the exclusion layer has created a 'hole' at that spot.

layerEx = layer2.not(exclusion_layer)
layerEx.merged(2).output("Overlap layer2 with exclusion layer")

But this doesn't work. The 'bottom-overlap' is gone (good!), but the 'top-overlap' is also gone (bad!).
I discovered that the boolean NOT operation creates a layer in the CLEAN state (the merging has already been
done by the NOT operation). (Calling merged(2) on an already merged layer is pointless.)

layer2.not(exclusion_layer).is_merged? returns true.

I tried the following, but that didn't work:

layerExRawRaw = input(2).raw.not(input(24).raw)
layerExRawRaw.merged(2).output("Overlap layer2 (RawRaw) with exclusion layer")

How do I use an exclusion layer that only creates 'holes' in another layer, while leaving the rest of that layer unchanged (the layer remains in raw-state)?

(We also need this exclusion layer for other checks than the overlap check.)

Thanks, Remco

Remark: I also have the GDS file and the DRC file, but this forum blocks uploading these files. The "Attach file" only allows uploading images, which is the same as the "Attach image" button. Looks like a bug?

I'm attempting to create a plugin (in Klayout 0.30.5) that loads a second layout if some conditions are triggered, and want to be able to use the plugin there. I'm having a bit of trouble understanding the structure of plugins and when the mouse_button_pressed_event etc. are actually called.

Here's the relevant skeleton of my code:

# $description: test
# $show-in-menu
# $menu-path: tools_menu>end("Test").end

import pya as kl

class PluginTestFactory(kl.PluginFactory):
    def __init__(self):
        self.add_submenu("menu_name", "inset_pos", "title")
        self.register(29318, "plugin_name", "test_plugin")
    def create_plugin(self, manager, dispatcher, view):
        return PluginTest(view)
class PluginTest(kl.Plugin):
    def __init__(self,view):
            self.curr_annot = kl.Annotation()
            self.curr_annot.p1 = kl.DPoint(0,0)
            self.curr_annot.p2 = kl.DPoint(0,0)
            self.curr_annot.fmt = ""
            self.curr_annot.fmt_x = ""
            self.curr_annot.fmt_y = ""
            self.curr_annot.outline = self.curr_annot.OutlineBox
            self.curr_annot.style = self.curr_annot.StyleLine
            view.insert_annotation(self.curr_annot)
    def mouse_button_pressed_event(self, p, buttons, prio):
        print("hello")
    def mouse_button_released_event(self, p, buttons, prio):
        self.match()
    def mouse_moved_event(self, p, buttons, prio):
        self.curr_annot.p2 = p

    def match(self):
        big_menu = kl.QDialog()
        big_menu.layout = kl.QGridLayout()
        containing_layout = kl.QWidget()
        self.layoutwidg = kl.LayoutViewWidget(containing_layout)
        cv = self.layoutwidg.view().create_layout(True)
        viewing_layout = self.layoutwidg.view().cellview(cv).layout()
        big_menu.layout.addWidget(self.layoutwidg,0,0,1,1)
        big_menu.show()

if __name__ == "__main__":
    PluginTestFactory()

When I click on the Tools>test menu button, a "test_plugin" button appears on the toolbar. The annotation appears and follows my mouse around before pressing the test_plugin button; I expected the annotation to appear, but the fact that it follows my mouse around implies that the mouse_moved_event is being called implicitly.

When I click the button in the toolbar, the "Basic Editing" pane pops up (why does that happen, by the way? It's annoying.), but no other effects occur; clicking and dragging and releasing does nothing. But when I open the debugger, I can put a breakpoint on the mouse_button_pressed_event and the mouse_button_released_event lines and it stops at both of them. If I step past the self.match() call, nothing else happens.

But if I step into the self.match() call and let it run, it opens up the QDialog I asked for. Within this QDialog, it appears that the mouse_button_pressed_event is completely inactive, whereas the mouse_button_released_event and mouse_moved_event calls are still active (in the sense that it stops at a breakpoint in the mouse_button_released_event function).

This is all very confusing to me, and I would like to understand what's going on. Is there some sort of infinite recursion being headed off by avoiding the self.match() call when the debugger breakpoint is absent, and is that why it isn't run?

The simplest question that would move me forward is: How do I force the mouse_button_pressed_event to be recognized in the layout in this pop-up window?

Thanks so much!

Noah

RuntimeError: Internal error: Terminal still connected after removing device in device combination: name=4, circuit=LNA_LAY_MAIN, terminal=mim_sub in Netlist::simplify in Executable::execute
.../ihp-sg13g2/libs.tech/klayout/tech/macros/.../lvs/sg13g2.lvs:388:in `simplify'
.../ihp-sg13g2/libs.tech/klayout/tech/macros/.../lvs/sg13g2.lvs:388:in `execute'
/built-in-macros/lvs_interpreters.lym:31:in `instance_eval'
/built-in-macros/lvs_interpreters.lym:31:in `execute'

I don’t fully understand what this error means. Could someone explain what could cause this “terminal still connected after removing device” error?
Any suggestions on how to debug or fix this ?

We are currently using the evaluate_nets function to implement the antenna checks for gf180mcu.

Here is the current implementation:

# ANTENNADIFFSIDEAREARATIO-like antenna check
def antenna_check_gf180mcu(gate, antenna_layer, thickness, limit, n_diode, p_diode, nwell, mf)
  expression = "var garea = area; var darea = area(n_diode) + area(p_diode) + area(nwell); var per = perimeter(antenna_layer) * thickness; "\
    "var ar = per / (garea + mf * darea); skip(ar < limit); "\
    "put('GATE_AREA', garea); put('DIODES_AREA', darea); put('ANT_PERIMETER', per); put('RATIO', ar);"
  variables = { "thickness" => thickness, "mf" => mf, "limit" => limit}
  return evaluate_nets(gate, { "antenna_layer" => antenna_layer, "n_diode" => n_diode, "p_diode" => p_diode, "nwell" => nwell }, expression, variables)
end

I have two questions:

• Is there a way to pass a list of layers?
• Is there a way to only issue one antenna violation for all gates on a net?

For the first question, I tried to adapt the antenna check as follows:

# ANTENNADIFFSIDEAREARATIO-like antenna check
def antenna_check_gf180mcu(gate, antenna_layer, thickness, limit, diodes, mf)
  expression = "var garea = area; var darea = 0; diodes.each { |diode| darea += area(diode) }; var per = perimeter(antenna_layer) * thickness; "\
    "var ar = per / (garea + mf * darea); skip(ar < limit); "\
    "put('GATE_AREA', garea); put('DIODES_AREA', darea); put('ANT_PERIMETER', per); put('RATIO', ar);"
  variables = { "thickness" => thickness, "mf" => mf, "limit" => limit}
  return evaluate_nets(gate, { "antenna_layer" => antenna_layer, "diodes" => diodes }, expression, variables)
end

And tried to use it like so:

antenna_check_gf180mcu(thin_gate, metal1, 0.54, 400, [n_diode, p_diode, nwell],  2)

Unfortunately, I get this error:

ERROR: RuntimeError: 'evaluate_nets': Second argument must be a hash of names and polygon in Executable::execute

Is there another way of passing a variable number of layers?

As for the second question, an antenna violation currently produces two items in the database (gate of nmos and gate of pmos). Is there a way to merge them?

Thanks!

Leo

I am working on a project involving Layout Dependent Effect (LDE) and Matching Analysis. To do this, I need to extract the exact physical location of every single device instance and map these coordinates to the extracted SPICE netlist.

I have performed an LVS run on a Sky130 design (see the attached image of the PMOS layout).

1. Observations regarding Coordinates:
In the results/lvs/pmos_sky130_lvs.lvsdb, I see structure definitions with coordinates (likely in DBU):

 D(D$sky130_fd_pr__pfet_01v8 sky130_fd_pr__pfet_01v8
  T(S R(l7 (-110 -300) (95 600)))
  ...
 )

And in the extracted netlist .cir, I see comments with coordinates in microns:

* device instance $1 r0 *1 2.065,7.57 sky130_fd_pr__pfet_01v8
M$1 VCC VCC VCC VCC ...

2. The Problem: Device Merging / Reduction
I noticed that the LVS process seems to merge/combine extracted devices.
As shown in the attached layout image, I have a multi-finger structure (or multiple separate devices). However, the generated LVS database and the extracted netlist seem to aggregate these into fewer device entries (e.g., M$1, M$2) with combined parameters (total W, combined Areas/Perimeters).

For my analysis, I need a 1-to-1 mapping. I need the extracted netlist to represent every single physical transistor finger (or at least every contiguous active area) as a separate subcircuit instance, without merging parallel devices.

My Questions:

1. Disabling Reduction: Is there a switch or a specific command in the Sky130 LVS runset (or generally in KLayout LVS scripts) to disable device combination/parallel merging? I want the "raw" extracted netlist where one layout geometry equals one netlist instance.
2. API for Coordinates: Instead of parsing the raw .lvsdb text file, is there a recommended Python/Ruby API to access the extracted device list and their specific coordinates (DTrans/Point)?

I want to write a script that iterates through the LVS results and prints something like:
Device M$1 (Finger 1): x=..., y=..., W=..., L=...
Device M$2 (Finger 2): x=..., y=..., W=..., L=...

Any guidance on how to configure the LVS to stop merging devices and how to query their locations via API would be extremely helpful.

Thank you!

I'm currently encountering a performance issue when running DRC.
Here’s the structure of my test layout and what I’ve observed:

I have one rule that checks area, and it runs much slower in deep mode.
In my test, the deep mode runtime is about 375 seconds, while the default (flat) mode only takes 22 seconds — roughly 10× faster.

I saw a talk mentioning that deep mode should actually be faster in some cases (if I understood correctly).
https://peertube.f-si.org/videos/watch/37358e7b-34f5-40c9-8fe9-f13a1825559a

I also tried different ways of writing the rule, such as using .drc(area) vs .with_area(), but there was no noticeable speed difference (unlike .drc(width) vs .width() which can differ).

Is there anything I can do to optimize or speed up my DRC in deep mode?

Thank you!

Laurent

threads(threads)

Although dummies are often a box, I have included an example with a polygon (a cross shape).
I have imagined all those dummies and theyr do not target a specific process and they will probably not fit with your target dummies density.

For further options, you can have a look at : https://www.klayout.de/doc-qt5/about/drc_ref_layer.html#k_37
or https://www.klayout.de/forum/discussion/550/using-the-fill-tool

Anyhow, it will generate the dummies cells directly on the toplevel cell.
Does anyone could help to improve my script to generate all those dummies in a separate cell called "DUMMIES_TOP" ? It would help a lot.

Thanks, BRgds,
Laurent

########################
# DUMMIES generation
########################

tstart = Time.now

if $in_gds
  if $topcell
    source($in_gds,$topcell)
  else
    source($in_gds)
  end
end

if $report_file
  report($report_file)
else
  report("DUMMIES generation runset", File.join(File.dirname(RBA::CellView::active.filename), "dumm.lydrc"))
end

require "logger"
log_file(File.join(File.dirname(RBA::CellView::active.filename), "log_DUMM.txt"))

# options
########################


# KLAYOUT setup
########################
# Use a tile size of 1mm
tiles(1000.um)
# Use a tile border of 10 micron:
#tile_borders(10.um)
no_borders

# hierarchical
deep

# Use 8 CPU cores
threads(8)
verbose(true)

# layers definitions
########################
info("Layers definitions")
NWELL = input(1,0)
ACTIVE = input(2,0)
POLY = input(3,0)
METAL1 = input(10,0)
METAL1_dmyblk  = input(10,2)
METAL2 = input(20,0)
METAL2_dmyblk  = input(20,2)
METAL3 = input(30,0)
METAL3_dmyblk  = input(30,2)
METAL4 = input(40,0)
METAL4_dmyblk  = input(40,2)

EXTENT_ALL = source.extent
EXCL_DIFPL = (NWELL + ACTIVE + POLY).sized(2.0)

ACT_fill = fill_pattern("DUMM_ACT")
hull =  [ RBA::DPoint::new(1, 0), RBA::DPoint::new(1, 1), RBA::DPoint::new(0, 1), RBA::DPoint::new(0, 2),
          RBA::DPoint::new(1, 2), RBA::DPoint::new(1, 3), RBA::DPoint::new(2, 3),  RBA::DPoint::new(2, 2),
          RBA::DPoint::new(3, 2), RBA::DPoint::new(3, 1), RBA::DPoint::new(2, 1),  RBA::DPoint::new(2, 0)]
ACT_fill.shape(2, 1, polygon(hull))
ACT_fill.origin(-1, -1)
(EXTENT_ALL - EXCL_DIFPL).fill(ACT_fill, hstep(4.0), vstep(4.0))

POLY_fill = fill_pattern("DUMM_POLY")
POLY_fill.shape(3, 1, box(0, 0, 3, 3))
POLY_fill.origin(-3, -3)
(EXTENT_ALL - EXCL_DIFPL).fill(POLY_fill, hstep(4.0), vstep(4.0))

M1_fill = fill_pattern("DUMM_METAL1")
M1_fill.shape(10, 1, box(0, 0, 3, 1))
M1_fill.origin(-1.0, -1.0)
(EXTENT_ALL - (METAL1.sized(3.0)) - METAL1_dmyblk).fill(M1_fill, hstep(4.0), vstep(2.0))

M2_fill = fill_pattern("DUMM_METAL2")
M2_fill.shape(20, 1, box(0, 0, 1, 3))
M2_fill.origin(-1.0, -1.0)
(EXTENT_ALL - (METAL2.sized(3.0)) - METAL2_dmyblk).fill(M2_fill, hstep(2.0), vstep(4.0))

M3_fill = fill_pattern("DUMM_METAL3")
M3_fill.shape(30, 1, box(0, 0, 3, 1))
M3_fill.origin(-1.0, -1.0)
(EXTENT_ALL - (METAL3.sized(3.0)) - METAL3_dmyblk).fill(M3_fill, hstep(4.0), vstep(2.0))

M4_fill = fill_pattern("DUMM_METAL4")
M4_fill.shape(40, 1, box(0, 0, 1, 3))
M4_fill.origin(-1.0, -1.0)
(EXTENT_ALL - (METAL4.sized(3.0)) - METAL4_dmyblk).fill(M4_fill, hstep(2.0), vstep(4.0))


time = Time.now
hours = ((time - tstart)/3600).to_i
minutes = ((time - tstart)/60 - hours * 60).to_i
seconds = ((time - tstart) - (minutes * 60 + hours * 3600)).to_i
info("DRC finished at : #{time.hour}:#{time.min}:#{time.sec}  -  DRC duration =  #{hours} hrs. #{minutes} min. #{seconds} sec.\n")
$stdout.write "DUMMIES generation finished at : #{time.hour}:#{time.min}:#{time.sec}  -  DRC duration =  #{hours} hrs. #{minutes} min. #{seconds} sec.\n"

Cheers

I have created an inverter.spice and inverter.gds and run the following command in the correct location of the $PDK_ROOT:

python3 run_lvs.py --layout=/home/slice/xschem/tb_inverter/LVS/inverter.gds --netlist=/home/slice/xschem/tb_inverter/LVS/inverter.spice --run_dir=/home/slice/xschem/tb_inverter/LVS --topcell=inverter --top_lvl_pins

Run however errors out complaining it has not found a cell name "inverter" for the layout.

Attached shows the error message and the contents of the extracted.cir.

Only new to this tool so quite confused about this error.
Any help most appreciated!

Thanks,

Diarmuid

sky130 has different simulation models for the standard nmos depending on the width of the transistor.
For a W >= 0.42 this is sky130_fd_pr__nfet_01v8 and for a W < 0.42 it's sky130_fd_pr__special_nfet_01v8.
Currently LVS is set up to simply extract all standard nmos using DeviceExtractorMOS4Transistor as sky130_fd_pr__nfet_01v8.

This means that LVS fails if a sky130_fd_pr__special_nfet_01v8 is used (such as in digital standard cells).

I see three solutions to this problem:

1. Convert back and forth

After reading in the netlist, simply convert all sky130_fd_pr__special_nfet_01v8 to sky130_fd_pr__nfet_01v8.
Before writing the extracted netlist, convert all sky130_fd_pr__nfet_01v8 with W < 0.42 to sky130_fd_pr__special_nfet_01v8.
(I would like to be able to simulate the extracted netlist, thus the conversion back.)

2. Extract the correct device type depending on W

Basically, reimplement DeviceExtractorMOS4Transistor in Ruby and create a sky130_fd_pr__special_nfet_01v8 device if W < 0.42, else sky130_fd_pr__nfet_01v8.

3. Create two new device extractors

SpecialDeviceExtractorMOS4Transistor -> only creates a sky130_fd_pr__special_nfet_01v8 device if W < 0.42
NonSpecialDeviceExtractorMOS4Transistor -> only creates a sky130_fd_pr__nfet_01v8 device if W >= 0.42

Option 1 seems to me to be the less clean solution. But option 2 and 3 require to basically reimplement the "extract_devices" function of the DeviceExtractorMOS4Transistor in Ruby. Perhaps there is a simpler/different way of doing this?

Looking forward to any thoughts on this

report("drc")

deep

Activ = source.polygons("1/0")
Cont = source.polygons("6/0")

# commenting the following line produces the expected result
Activ.with_density(0.0 .. 0.35, tile_size(20.0.um))

Cont.output("Cont")
Activ.output("Activ")
Cont.join(Activ).output("Cont.join(Activ)")

In 0.29.7, the two hierarchical layers are properly joined. In later versions (I've checked 0.29.9 and 0.29.11), the join is missing shapes in lower hierarchy levels. Disabling the density check produces the correct/expected result! Interestingly, even Activ.dup.with_density(...) changes the behavior of the join operation!

I have compiled all versions from source on Arch Linux. Can anyone reproduce this issue? If required, I can also create a simple example layout.

    connect(m1, via)
    connect(via, m2)
    connect(m2, via2)
    connect(via2, m3)
    connect(m3, via3)
    connect(via3, m4)
    connect(m4, via4)
    connect(via4, m5)

How to select m1 shapes that are connected to m5?

Let's say that we have two layers A and B. I would like to detect shapes of layer B that are between two layer A shapes - assuming that we are only dealing with rectangular shapes.

This is the shape I would like to be detected.

I was considering using interacting (using min and max) and outside/inside (to exclude overlapping shapes) operations but I am not entirely sure how to avoid detecting this scenario

Thank you

I'm playing around with the DRC fill tool and got some questions (version 0.28.17):

1) I would like to fill a layer called "layer_to_fill" (green in the screenshots below) with a tile "tile_M1" (blue in the screenshots below):

tile_M1 = fill_pattern("TILE_M1").shape(20170, 0, box(-0.244, -0.240, 0.244, 0.240))
layer_to_fill.fill(tile_M1)

This works great:

If I redo this with an offset, I see that the tiles are shifted as expected, but there are now also tiles going outside the "layer_to_fill" shapes (ellipse)...
I would not expect this to happen or am I missing something???

tile_M1 = fill_pattern("TILE_M1").shape(20170, 0, box(-0.244, -0.240, 0.244, 0.240))
tile_M1.origin(-0.3, -0.3)
layer_to_fill.fill(tile_M1)

2) Is there a way to refer to an existing cell of the layout, instead of using the fill_pattern method and add shapes one by one via code???

Cheers,

Tomas

obj = pya.Path(points, width, bgn_ext, end_ext, r)
print(obj) # (0,0;1,0;1,1;2,1) w=1 bx=1 ex=1 r=true

From the print result I get right result. But when I export it into KLayout. The end is still rectangular rather than round. Is this a bug?

I'm trying to run LVS on a "top level" assembly (on the iHP PDK).

This cell is really only assembling other subcells, there are no active devices at all.
Those subcells have passed their own LVS and can be considered good, so really all I want to do is check that the metal/via make the connection they should between the subcells. Those connections can be varied ( so multiple pins of multiple cells connected to the same net ).
Those subcells also have multiple "power pins" exposed and it must be checked that all of them are connected properly.

I was however not able to achieve any of that after trying various approaches.

The very first issue is that I couldn't find any way to black box the extraction itself so that it doesn't extract the "insides" of the subcells.
There is a blank_circuit ( and netlist and schematic variants of it which I found out are apparently case sensitive ... ) but AFAICT this acts only after extraction. And that's just no good because the extraction step itself doesn't complete (or at least not in any reasonable time, I have a run that's still running after 12 hours at time of writing this ... ).

I tried instead feeding a GDS where I had manually stripped the subcells to only the pins but I couldn't get that to work either.

So is what I want to do possible with KLayout or should I just give up on it ?
And if it is, then what's the approach I should be doing ?

Cheers,

Sylvain

There are design rules for creating slits in wide metal wire.
While I can easily code the width check, I’m not sure how to
code the length check.
Metal (actual) = Metal (data) – Slit (data)
Slit data design rules.
(Where Length　> Width)
rule1: Width　>= a um　 （Min. W) - width check
rule2: Length >= b um　 （Min. L) - how to check?
rule3: c um >= Length >= b um (Max. L) - how to check? (optional)

Could anyone advise on which commands or functions?
Thanks,

* Created by KLayout

.SUBCKT TOP
D$1 1 1 diode_dev A=152519.75592P P=1563.728U
D$2 2 2 diode_dev A=155127.109292P P=1576.494U
D$3 3 3 diode_dev A=151327.92696P P=1557.344U
.ENDS TOP

To this output:

* Created by KLayout

.SUBCKT TOP
DDev_A 1 1 diode_dev A=152519.75592P P=1563.728U
DDev_B 2 2 diode_dev A=155127.109292P P=1576.494U
DDev_C 3 3 diode_dev A=151327.92696P P=1557.344U
.ENDS TOP

Where Dev_A, Dev_B, Dev_C are labels on each respective diode.

I initially thought of creating a custom device extractor that takes in an extra terminal for labels, but from what I've seen no text data gets passed.
Here is an example of the extractor: (Example copied from here: https://www.klayout.de/forum/discussion/2178/problems-encountered-when-changing-the-terminal-declaration-in-the-device-class)

class DiodeExtractor < RBA::GenericDeviceExtractor

  def initialize(name)
    self.name = name
  end

  def setup
    define_layer("P", "Anode")
    define_layer("N", "Cathode ")
    register_device_class(RBA::DeviceClassDiode::new)
  end

  def get_connectivity(layout, layers)
    conn = RBA::Connectivity::new
    conn.connect(layers[0], layers[1])   # collect touching contacts
    conn.connect(layers[1], layers[1])   # combine resistor shapes into one area
    conn
  end

  def extract_devices(layer_geometry)    #layer_geometry are Region Datatypes, no text?
    anode = layer_geometry[0]
    cathode  = layer_geometry[1]
    diode_regions= (anode & cathode).merged
    a = diode_regions.area*dbu*dbu
    p = diode_regions.perimeter*dbu
    device = create_device
    #device.name = "Fred_The_Lonely_Diode"    #If text can be passed then this is where the device would be renamed.
    device.set_parameter(RBA::DeviceClassDiode::PARAM_A, a)
    device.set_parameter(RBA::DeviceClassDiode::PARAM_P, p) 
    define_terminal(device, RBA::DeviceClassDiode::TERMINAL_A, 0, anode[0]);
    define_terminal(device, RBA::DeviceClassDiode::TERMINAL_C, 1, cathode[0]);
  end

end