@Mitch Bailey Im having some trouble with my lvs between my schematic and layout. It keeps saying there are disconnected nodes and the tries to compare again. It doesnt seem to me like they are actually disconnected though so I am not sure what to do. If anyone could provide some guidance it would be appreciated!

@Konnor Kivimagi Try removing this simulation code from the schematic netlist.

**** begin user architecture code

.subckt sky130_fd_pr_reram__reram_cell TE BE Tfilament_0=3.3e-9 area_ox=0.1024e-12
N1 TE BE nFilament sky130_fd_pr_reram__reram_model
.ic v(nFilament)={Tfilament_0*1.0e9}
.ends sky130_fd_pr_reram__reram_cell

.model sky130_fd_pr_reram__reram_model sky130_fd_pr_reram__reram_module  area_ox = 0.1024e-12  Tox =
+ 5.0  Tfilament_max = 4.9  Tfilament_min = 3.3  Eact_generation = 1.501  Eact_recombination  = 1.500
+  I_k1  = 6.140e-5  Tfilament_ref = 4.7249  V_ref = 0.430  velocity_k1 = 150  gamma_k0  = 16.5  gamma_k1
+  = -1.25  Temperature_0 = 300  C_thermal = 3.1825e-16  tau_thermal = 0.23e-9  t_step  = 1.0e-9
+  smoothing = 1e-7  Kclip = 200

.control
pre_osdi
+ /home/kivimagi/reram/caravel_user_project/dependencies/pdks/sky130B/libs.tech/ngspice/sky130_fd_pr_reram__reram_module.osdi
.endc

@Mitch Bailey That solved that issue however now the netlists dont quite match up. Do you understand what the issue is? Im not quite sure I understand.

@Konnor Kivimagi I think you need to remove the

sky130_fd_pr_reram__reram_cell

from the source spice netlist.

@Mitch Bailey Thanks for your help! That cleared up the issue and they match now. Out of curiosity there are some property errors with the reram cell. Are those going to potentially cause any errors later?

@Konnor Kivimagi that property error should not show up. What version of the pdk are you using?

volare ls

@Mitch Bailey I am not sure, how can I find that?

volare ls

does not work for me

Ah. What command are you using to run netgen? If you’re using the raw netgen command, don’t forget the setup file

netgen -batch lvs "layout.spice layout_cell" "netlist.spice netlist_cell" $PDK_ROOT/$PDK/libs.tech/netgen/${PDK}_setup.tcl

The property errors are gone now. I installed the PDK again and the property errors dissappeared. Thanks for all your help!

@Konnor Kivimagi Have you set

export PDK=sky130B

?

@Mitch Bailey Thanks I had not done that, that fixed the nets match uniquely. Now I am getting those property errors again but I am pointing to the correct PDK however it says

Warning: device level LVS may be incomplete due to 1 unflattened cell(s)

Could that be my problem and how might I solve that?

Is this the local precheck? You might be using an older version. How are you running lvs?

Hi, @Konnor Kivimagi, @Mitch Bailey I also have a problem with the lvs of sky130_fd_pr_reram__reram_cell. When I do MPW precheck on the server, When I do MPW precheck on the server, the precheck does it with sky130A. Because of this, it doesn't recognize sky130_fd_pr_reram__reram_cell and lvs problem occurs. Are there any issues with this? And I passed with local prechecks.

@Yonguk Sim I think you are going to have to skip LVS in precheck. As long as you are passing locally, you should be ok. I’ll raise this issue with the efabless team and let you know if they have other instructions.

@Mitch Bailey Thanks for the advice.

@Mitch Bailey This is the local precheck. I am running it with

make run-precheck

from

caravel_user_project_analog

The LVS is the last step its trying to check.

@Konnor Kivimagi the

mpw_precheck_log.txt

check that @Yonguk Sim shared has the pdk set to sky130A.

STDOUT: {{PDKs Info}} SKY130A: None | Open PDKs: 0fe599b2afb6708d281543108caf8310912f54af

If this is the local precheck, run the following command first.

export PDK=sky130B

@Mitch Bailey before my last try I had run

export PDK=sky130B

and that fixed the netlists not matching, however those property errors still persist. I cant find

mpw_precheck_log.txt

where does that normally output to?

That may have been a screen log capture by @Yonguk Sim. You’ll have to ask them. Do you have a file here?

precheck_results/<timestamp>/logs/precheck.log

@Mitch Bailey yes I do

Can you share this file?

/home/kivimagi/reram/caravel_user_project_analog/precheck_results/15_SEP_2024___00_06_18/logs/LVS_check.log

LVS_check.log

Looks like you have an older version of precheck

/home/kivimagi/PDK/sky130B/libs.tech/magic/sky130B.tech: version 1.0.470-0-g6d4d117
/home/kivimagi/mpw_precheck/checks/be_checks//tech/sky130B/sky130B.tech: version 1.0.446-0-gdd7771c

Can you change

MPW_TAG

in the Makefile to

2024.09.13-1

and then run

make precheck
make run-precheck

Just reran it and the LVS errors are still present. The Lvs looks the same as when you had me remove

sky130_fd_pr_reram__reram_cell

from the source netlist earlier, but i am unable to do that now do to it coming from the .gds file

Just to be sure. You are running local precheck.

PDK

is set to

sky130B

.

MPW_TAG

is set to

2024.09.13-1

in the

Makefile

. What version of the PDK are you using? Can you try with this version?

$ volare ls
In /opt/pdks/volare/sky130/versions:
├── 0fe599b2afb6708d281543108caf8310912f54af (2024.08.17) (enabled)

Can you attach your

LVS_check.log

and

lvs.report

?

Those are all correct, how can I change the PDK version? This is the one i am using currently`6d4d11780c40b20ee63cc98e645307a9bf2b2ab8`

volare enable 0fe599b2afb6708d281543108caf8310912f54af

The precheck version still appears to be old. Can you share your

Makefile

?

Makefile

@Konnor Kivimagi Looks good. Just to be sure that it’s not being overridden, does this print anything?

echo $MPW_TAG

When you run

make precheck

, can you see the version being downloaded?

echo $MPW_TAG

does not print anything.

remote: Enumerating objects: 236, done.
remote: Counting objects: 100% (236/236), done.
remote: Compressing objects: 100% (176/176), done.
remote: Total 236 (delta 76), reused 145 (delta 49), pack-reused 0 (from 0)
Receiving objects: 100% (236/236), 10.15 MiB | 4.66 MiB/s, done.
Resolving deltas: 100% (76/76), done.
Note: switching to '0941bdc1b62b5c3f99c8683bd11199d330af2ef3'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

Updating files: 100% (238/238), done.
Trying to pull <http://docker.io/efabless/mpw_precheck:latest|docker.io/efabless/mpw_precheck:latest>...
Getting image source signatures
Copying blob 446f83f14b23 skipped: already exists  
Copying blob a33f1a51bb0d skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob a978b6397646 skipped: already exists  
Copying blob 7e50b4b8ee26 skipped: already exists  
Copying blob 9bfd1ff29161 skipped: already exists  
Copying blob 7622a4fc0077 skipped: already exists  
Copying blob 2960fe10ac99 skipped: already exists  
Copying blob 88703f993b8a skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob cda7266f6049 skipped: already exists  
Copying blob a8d0fa0056b2 skipped: already exists  
Copying blob 0ed9ea9f0f89 skipped: already exists  
Copying blob df4c5942c2fb skipped: already exists  
Copying blob 27662f800ba7 skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 1b8f752dd2a6 skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 066586644a86 skipped: already exists  
Copying blob 29a472ae3270 skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob e67d7c1673ea skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 04ee5843b197 skipped: already exists  
Copying config 811cdd989a done  
Writing manifest to image destination
811cdd989a0dc59c3f6d0cb81fcb72302bc324536104d5d7a194a0da0f793739

is what i get running

make precheck

Thanks for helping to debug this issue. That appears to be the correct mpw_precheck repo. Is

PRECHECK_ROOT

set? If it is, can you share the first 20 lines of

$PRECHECK_ROOT/checks/be_checks/tech/sky130B.tech

? If it is not set, can you share the first 20 lines of

$HOME/mpw_precheck/checks/be_checks/tech/sky130B.tech

?

Heres the first 20 lines of

$HOME/mpw_precheck/checks/be_checks/tech/sky130B.tech

#------------------------------------------------------------------------
# Copyright (c) 2020 R. Timothy Edwards
# Revisions:  See below
#
# This file is an Open Source foundry process describing
# the SkyWater sky130 hybrid 0.18um / 0.13um fabrication
# process.  The file may be distributed under the terms
# of the Apache 2.0 license agreement.
#
#------------------------------------------------------------------------
tech
  format 35
  sky130B
end

version
 version 1.0.493-0-g0fe599b
 description "SkyWater SKY130: Open Source rules and DRC"
 requires magic-8.3.411
end

That looks correct. But that does not match the results in

LVS_check.log

, so I’m confused. Does

make lvs-user_analog_project_wrapper

give a clean LVS result?

Traceback (most recent call last):
  File "/home/kivimagi/mpw_precheck/checks/lvs_check/lvs.py", line 7, in <module>
    from checks.utils import utils
ModuleNotFoundError: No module named 'checks'
make: *** [Makefile:99: lvs-user_analog_project_wrapper] Error 1

make lvs-user_analog_project_wrapper

does not work

That is unexpected. I’m not sure why that is happening, but I verified it on my side too. If you change the Makefile line from

python3 checks/lvs_check/lvs.py

to

python3 -m checks.lvs_check.lvs

I think it will work.

That allowed it to run, the lvs did not pass though. Seems to be the same problem that i initially had comparing two netlists but I am unable to edit it because its using the .gds to compare

Do you have a layout cell in the gds named

sky130_fd_pr_reram__reram_cell

?

it was created in magic yes

I apologize if I wasn’t clear. Was the

sky130_fd_pr_reram__reram_cell

created manually in magic or automatically using a device generator located in the

Devices 1

or

Devices 2

menus?

I created it manually from the pins "TE" and "BE" that were imported from the spice file. The only thing I used from the device menus were the vias

I understand. Just rename the layout cell so that it does not conflict with the extracted device name and it should pass.

I did that and I got a new property error

Netlists match uniquely with property errors.
x1T1R:1T1R_0/sky130_fd_pr_reram__reram_cell_X:XR1/sky130_fd_pr_reram__reram_cell:0 vs. 1T1R:1/sky130_fd_pr_reram__reram_cell:R1:
Property area_ox in circuit1 has no matching property in circuit2

I was able to fix that by removing

area_ox=1

from line 4 in the file I attached. Is there a file that I can edit so that part doesnt get generated in the .gds file? Seems like it will work as long as that little section doesn't get added.

What version of the pdk are you using?

volare ls

(toolchain) [kivimagi@linuxvdi-38 ~]$ volare ls
In /home/kivimagi/PDK/volare/sky130/versions:
└── 6d4d11780c40b20ee63cc98e645307a9bf2b2ab8 (2024.02.11) (enabled)

Thank you I appreciate it, I will poke around at it some more today as well

You might try changing

MPW_TAG=2024.09.13-1

and

export OPEN_PDKS_COMMIT?=0fe599b2afb6708d281543108caf8310912f54af

in the

Makefile

followed by

make pdk-with-volare
make precheck

No dice, still getting the same property error

Ok, let’s try the other way. Can you add the

area_ox

parameter to your schematic and re-netlist? The device size is 1umx1um, right?

Add it in to the schematic like this? In the reram cell properties or another way?

Huh. Can you manually add it to the schematic netlisted spice?

@Mitch Bailey That did it! I got it to succesfully pass precheck. Thanks so much for helping me through this.