Hi everyone, I've just installed OpenLane, generated the test

spm

project with

$ make test

, and I'm now staring at the

spm.gds

file through the latest build of KLayout. However, one thing that is confusing is the layer naming (see attached screenshot) - I've told KLayout where to find the

Sky130A.lyp

file, but I'm still getting stuff on layers with no real name - could anyone suggest what's the meaning of these layers?

I don't see any routing layers in the layer list, so I'm guessing that there was a problem with the technology used for openlane. Was your

PDK_ROOT

set correctly?

Hi Mitch, what should the routing layers be called? I also forgot to mention, that in the list I right-click enabled the "Hide empty layers" feature, the full list has many many more layers, but I'm guessing since they're empty they're probably not interesting. Regarding the

PDK_ROOT

, if I

$ make mount

myself into the OpenLane container, then I see the following:

OpenLane Container (c0be543):/openlane$ echo $PDK_ROOT
/home/maxim/prj/skywater/OpenLane/pdks
OpenLane Container (c0be543):/openlane$ ls $PDK_ROOT
sky130A  sky130B  volare

It did just occur to me, that at no point did I specify that OpenLane should use

SKY130A

when running the synth job - is it possible that its using

volare

by default, and I'm trying to open it in "`SKY130A`" mode?

Looks like PDK_ROOT is ok.

met2/drawing

,

via/drawing

,

met3/drawing

, etc. are routing layers.

sky130A

is probably set in the

config.tcl

file.

Hi Mitch, actually my

designs/spm

directory doesn't have a

config.tcl

- I do have a

config.json

though, but it doesn't mention using the sky130A process anywhere:

{
  "DESIGN_NAME": "spm",
  "VERILOG_FILES": "dir::src/*.v",
  "CLOCK_PERIOD": 10,
  "CLOCK_PORT": "clk",
  "CLOCK_NET": "ref::$CLOCK_PORT",
  "FP_PDN_VOFFSET": 7,
  "FP_PDN_HOFFSET": 7,
  "FP_PIN_ORDER_CFG": "dir::pin_order.cfg",
  "pdk::sky130*": {
    "FP_CORE_UTIL": 45,
    "scl::sky130_fd_sc_hd": {
      "CLOCK_PERIOD": 10
    },
    "scl::sky130_fd_sc_hdll": {
      "CLOCK_PERIOD": 10
    },
    "scl::sky130_fd_sc_hs": {
      "CLOCK_PERIOD": 8
    },
    "scl::sky130_fd_sc_ls": {
      "CLOCK_PERIOD": 10,
      "SYNTH_MAX_FANOUT": 5
    },
    "scl::sky130_fd_sc_ms": {
      "CLOCK_PERIOD": 10
    }
  }
}

is that unexpected?

The switch to json is a recent change, I think. Can you add

"PDK": "sky130A",

to the json file, rerun and see what happens?

Hi Mitch, I haven't let the non-

"PDK": "sky130A",

run finish yet, but just looking at the very first log entries, they both start the same way:

[INFO]: Using configuration in 'designs/spm/config.json'...
[INFO]: PDK Root: /home/maxim/prj/skywater/OpenLane/pdks
[INFO]: Process Design Kit: sky130A
[INFO]: Standard Cell Library: sky130_fd_sc_hd
[INFO]: Run Directory: /openlane/designs/spm/runs/openlane_test
...

IIRC, there may be a klayout gds and a magic gds. Do they both have the same problem? There should also be a

mag

directory somewhere under the

runs

directory. You can open that file with a text editor to check the existence of routing layers (

met2

, etc.). Sounds like it might be a problem reading the magic tech file, but I don't know for sure. Can you find the

open_pdks

commit tag?

Hi Mitch, I don't seem to have any of those directories that you mentioned - here is the directory structure that I see:

maxim@thinkpad:~/prj/skywater/OpenLane/designs/spm$ ll runs/openlane_test/results/signoff
total 5068
drwxr-xr-x  2 maxim maxim    4096 Aug 18 00:52 ./
drwxr-xr-x 10 maxim maxim    4096 Aug 18 00:52 ../
-rw-r--r--  1 maxim maxim    3503 Aug 17 15:09 .magicrc
-rw-r--r--  1 maxim maxim  901455 Aug 18 00:52 spm.drc.mag
-rw-r--r--  1 maxim maxim 1155350 Aug 18 00:52 spm.gds
-rw-r--r--  1 maxim maxim  607492 Aug 18 00:52 spm.klayout.gds
-rw-r--r--  1 maxim maxim    9068 Aug 18 00:52 spm.lef
-rw-r--r--  1 maxim maxim    7073 Aug 18 00:52 spm.lef.mag
-rw-r--r--  1 maxim maxim   80548 Aug 18 00:52 spm.lef.spice
-rw-r--r--  1 maxim maxim  237579 Aug 17 15:09 spm.lyp
-rw-r--r--  1 maxim maxim  914222 Aug 18 00:52 spm.mag
-rw-r--r--  1 maxim maxim 1155350 Aug 18 00:52 spm.magic.gds
-rw-r--r--  1 maxim maxim   80548 Aug 18 00:52 spm.spice

If I

grep

for

'met'

in the

spm.mag

file, then I do see various references to metal:

$ egrep -C 2 'meta' runs/openlane_test/results/signoff/spm.mag | head
rect 17601 2397 17635 2431
rect 10885 2261 10919 2295
<< metal1 >>
rect 16574 20612 16580 20664
rect 16632 20652 16638 20664
--
rect 19265 2150 19317 2202
rect 19329 2150 19381 2202
<< metal2 >>
rect 1582 21714 1638 22514

along with others:

<...trimmed...>
port 21 nsew signal input
flabel metal2 s 15382 21714 15438 22514 0 FreeSans 224 90 0 0 x[25]
port 22 nsew signal input
flabel metal2 s 15934 21714 15990 22514 0 FreeSans 224 90 0 0 x[26]
port 23 nsew signal input
flabel metal2 s 16486 21714 16542 22514 0 FreeSans 224 90 0 0 x[27]
port 24 nsew signal input
flabel metal2 s 17038 21714 17094 22514 0 FreeSans 224 90 0 0 x[28]
port 25 nsew signal input
flabel metal2 s 17590 21714 17646 22514 0 FreeSans 224 90 0 0 x[29]

Ok. So the

mag

file has metal2 (gds layer

69/20

), but that's not showing up in klayout when you open

spm.klayout.gds

. What do you get when you open

spm.gds

? (Your post says that you're looking at

spm.gds

but the screen shot shows

spm.klayout.gds

)

With

spm.gds

, it looks like I get the metal layers (Still not sure what the

83/44

or

236/0

is referring to at the bottom):

My klayout shows

83/44

as

text.drawing

and

236/0

as

OUTLINE

. I believe the

spm.gds

and

spm.magic.gds

had the same file size. Can you do a diff? I believe that openlane creates both magic and klayout gds files and compares them. But maybe there's an issue where it only compares layers that are in both files while ignoring layers that are only in one of the files. Is there a

*.xor.log

file in your

runs

directory?

Looks like they're the same:

OpenLane Container (c0be543):/openlane/designs/spm/runs/openlane_test/results/signoff$ md5sum *.gds
c4df9edfc74fe0aeeeec55fd7f14a5ad  spm.gds
df3b50307d57110d6b16685df016c9a2  spm.klayout.gds
c4df9edfc74fe0aeeeec55fd7f14a5ad  spm.magic.gds

Regarding the

*.xor.log

, I don't have a

runs

directory, but I did a

grep

for the filename and found the following:

OpenLane Container (c0be543):/openlane/designs/spm/runs/openlane_test$ find . -type f | egrep '\.xor'
./reports/signoff/spm.xor.gds
./reports/signoff/spm.xor.xml

/openlane/designs/spm/*runs*/openlane_test Are the xor results (gds and xml) empty?

The gds and xml files aren't empty (see attached)

Looks like it is flagging all the differences.