I have tried to transfer a SKY130 magic file .mag to KLayout. It can be read, but the GDS numbers are not OK, only the layer names even if I use the layer mapping such as (also attached) :
NWELL:64/20
DIFF:65/20
TAP:65/44
DNWELL:64/18

What is the proper method to read a SKY130 mag file with KLayout ? Maybe the mapping is sensitive to layer name case ?

Thank you, BRgds,
Laurent

• OASIS vs. GDS: Time to switch? (Semiconductor Digest)

• From GDSII to OASIS (Tech Design Forum)

I have personally switched to OASIS after Mattias pointed out that OASIS saves Layer names (in addition to layer numbers), and subsequently found that my file sizes would go from 150MB (GDS) --> 25kB (OAS), an even more important fact for transferring GB-level files. It's now my standard format, converting to GDS only on the writing tools that require it (Heidelberg for example).

I'm tempted to write a qt widget macro to do it myself, but I don't want to duplicate work if there is already a good method.

How exactly does the manual conversion work without using Python code?
Experts, please help me

lay::LayoutView lv(0, false, 0);
lv.set_drawing_workers(2);
lv.cell_box_color(tl::Color(0, 0, 0));

lv.load_layout("D:/vs2017/klayout/build/collect_basic_bg.gds", true);

tl::PixelBuffer img;
img = lv.get_pixels_with_options(500, 500, 1, 1, 1.0, 1.0, tl::Color(255, 255, 255), tl::Color(0, 0, 0), tl::Color(128, 128, 128), db::DBox());

Thank you,
dai

1. how to convert gds to dxf through a script
   (I Know this is a duplicate question but, i want to know a brief example)

2. how to set convert options
   (gds layerNumber → dxf layerName, Color)

I really need help..

Thanks to this post (Error reading GDSII file), i was able to use dump_oas_gds2 to view a GDS file that throws an error in the current version of Klayout. I have created my own script that allows me to export GDS files, so I would consider the problem solved, but it did raise two questions:

1. I am curious if anyone would comment on the difference between Klayout 0.27+ and previous that allows the older versions to view the file? I can use 0.24.10 to view the file without error.

2. Is there any suggested way of editing a GDS file that won't open in Klayout, or perhaps, editing in an older version to allow it to work in newer versions of Klayout?

I would like to convert a Calibre .rul file into a .lydrc file that can be recognized by KLayout. Does KLayout provide this functionality, or are there any related scripts available elsewhere?

def main():
# input_file and output_file are the paths of input and output files respectively
input_file = "D:\line4.GDS"
output_file = "D:\line4.dxf"

print("Input GDS file:", input_file)
print("Output DXF file:", output_file)

layout = Layout()
layout.read(input_file)
print("111")
try:
    dxf_stream = DxfOutput()
    print("222")
except Exception as e:
    print("Error:", e)
    return


print("222")

layout.write(dxf_stream)
print("333")

dxf_stream.save_as(output_file)
print("444")

print("Conversion complete.")

if name == "main":
main()
"
But I can't get the dxf file correctly. I hope I can get your help.

for each_gds in gds_files:

KLAYOUT.read(each_gds)
#print("Cells : ",KLAYOUT.top_cell().name)
#print("Layers : ",KLAYOUT.layers())

#print("each",KLAYOUT.each_cell())
for ly_id in KLAYOUT.layer_indices():

#print ("Layer_info: ",KLAYOUT.get_info(ly_id))
layer_name =KLAYOUT.get_info(ly_id)
print('layer_name:',layer_name)
#sh = KLAYOUT.top_cell().each_shape(0)

# print ("shape area : ", sh)
layer = KLAYOUT.layer(layer_name)
#print(layer)
area = 0
for cell in KLAYOUT.each_cell():
#print(cell)
for shape in cell.each_shape(layer):
area += shape.area()
print(area)

In this i want store all area value in one txt formate document.
anyone know this ?

Hello,
I have a problem regarding the LVS verification: it says that the hierarchical LVs are not good, but all my sub-circuits have been verified with a good LVS. I show you an example with not_opt1.

This is the first time I've had this problem, do you have any idea where it's coming from?

Is there a way to load SPICE netlists which include transistor models via .lib statements?

The characterization tool lctime (Python) uses KLayout for parsing and analyzing spice netlists. That worked quite well for simple netlists. However, things seem to be more complicated as soon as .lib control statements are used to include transistor models. KLayout ignores control statements.

In the following example the .lib statement is skipped and therefore the transistor models will not be found.

.lib "/XYZ/sky130/skywater-pdk-libs-sky130_fd_pr/models/sky130.lib.spice" tt

.subckt thesis_inv A Y VPWR VGND
X0 Y.t1 A.t0 VPWR.t1 VPWR.t0 sky130_fd_pr__pfet_01v8 ad=1.25045 pd=6.51 as=1.2364 ps=6.5 w=2.81 l=0.15
X1 Y.t0 A.t1 VGND.t0 VGND sky130_fd_pr__nfet_01v8 ad=0.3916 pd=2.65 as=0.3872 ps=2.64 w=0.88 l=0.15
.ends

sky130.lib.spice contains .include statements in the following form:

* Typical corner (tt)
.lib tt
.include "../a.spice"
.include "../b.spice"
.endl

* Slow-Fast corner (sf)
.lib sf
*...
.endl

*...

I see that NetlistSpiceReaderDelegate has a method 'control_statement'. However, I don't understand yet how it could be used to load .lib-style includes.

I'd appreciate any hints!

Thanks & best regards
Thomas

I noticed something weird (KLayout 0.27.10):

1) Original file with DBU = 0.00005: TEST2.gds
2) Saving as OAS file with the same DBU: TEST2.oas
3) Saving original file "TEST2.gds" as GDS file with DBU = 0.0001: TEST2_DBU_0p1nm.gds
4) Saving file "TEST2.oas" as OAS file with DBU = 0.0001: TEST2_DBU_0p1nm.oas

Files "TEST2.gds" and "TEST2.oas" are geometrically identical, as expected.

But files "TEST2_DBU_0p1nm.gds" and "TEST2_DBU_0p1nm.oas" are not geometrically identical. It seems the snapping to the new DBU is different for GDS and OAS files. The GDS versions looks ok (snapping to larger DBU as expected), but in the OAS version some small 0.1nm gaps appear, for instance in the "6" character.

Can you reproduce?

Cheers,

Tomas

I am trying to understand the file format details of this MEBES file. Can you point me to a way to get the detailed description of this format, or how to purhcase such format from AMAT?

Thanks
enuinc

I faced with the following issue.
I tunned options for DEF import in "Technology Manager->Reader options->LEF/DEF->Production".
I enabled "Routing" and "Special routing" and defined "Layer name Suffix" and "GDS data type" for each of them.
And after I exported Technology data to XML file (see attached Tech_export.txt).

In this file I see that the field names are equal for routing and special routing and second overwrites first one.
In result, after such XML importing I see in technology manager, that fields for Routing are filled with data from Special routing and fields for Special routing are empty.

Is this a bug and how can I fix it? I tried to rename to e.t.c without any success.

while trying to convert a photolitography mask made in AutoCAD (.dwg) to a klayout compatible file (.dwg) I stumbled upon some issues already discussed in the forum before. After adjusting the reader options(I tried 1e-06 and 1e-04 for database unit as well), the coordinate overflow error still remains. Are there any alternative approaches that can be tried to repair this?
Link to files: https://easyupload.io/m/bce0kv

Kind regards