Hello, I am attempting to create a 1T1R cell that passes LVS. I was able to create the layout, and when I ran LVS I was able to get it to pass, but my layout had "property errors." I was wondering if it is okay to ignore these property errors, or if I am doing something wrong in my layout? Any help is greatly appreciated.

There is a property called "Tfilament_0" in the schematic netlist for the ReRAM device. You just need to have a local copy of the setup file and add:

property "-circuit2 sky130_fd_pr_reram__reram_cell" delete Tfilament_0

This is not an extractable property so it does not exist in the layout netlist. I can add this to the PDK so that the default setup file for sky130B will have that line.

That did it! Thank you so much for the fast response!

@Tim Edwards correct me if I’m wrong, but it looks like

sky130_fd_pr_reram__reram_cell

is being treated as a primitive device (subckt with no elements) in the schematic but not in the layout. Doesn’t the introduce the possibility of a false match? The actual device extracted in the layout is

sky130_fd_pr__reram_reram_cell

and is being ignored. In the source netlist, there is an

N

device instance of

sky130_fd_pr_reram__reram_model

, but I doubt that magic/netgen supports device statements that begin with

N

.

.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

@Joshua Thater The schematic netlist you’re using for LVS looks like a simulation version of the netlist that contains control and model statements. It’s been recommended that you put the statements used for simulation in a test bench wrapper.

I definitely need to fix all the ReRAM issues. I'll look at it some more tomorrow.

I'll just throw this in here, I don't know if it will be helpful or not. This is a picture of the schematic I used to generate the schematic netlist. It uses a recent version of the Open PDKs, which has the updated symbol model of the ReRAM, which, I believe, allows it to be compatible to be simulated with Ngspice. So, the extra control statements are built into the the ReRAM symbol itself. When I import the spice netlist of just the ReRAM cell into Magic it generates 4 pins in Magic and I don't know if this is intended.

Thanks @Joshua Thater, doesn’t look like there’s much else you can do on your side.

Hello @Tim Edwards and @Mitch Bailey, I am reviving this thread as I am having basically the same exact issue and was curious if a solution was ever constructed. I am taking a simple reRAM cell, as well as an analog MUX, through precheck as a means to ensure I can get the basic reram process down before integrating it with other modules. With that, I have been getting the same issues that have arised in this thread. I got the same property errors, altered the setup file to include the line ignoring the Tfilament_0, which got rid of the errors. The circuits now match uniquely, however, the reram cell is empty for my xschem circuit, much like what was mentioned above. Did you guys ever comprise a resolution for this problem?

@Travis Jakl: I suggest renaming the outer cell in the layout, since

sky130_fd_pr_reram__reram_cell

is the lowest-level subcircuit; then the two circuits should match because netgen will match the lowest level subcircuit on both sides, since netgen does not (that I know of) understand the

N

component.

@Tim Edwards it seems as though renaming the outer cell, as well as just deleting the .subckt module all together both result in a successful lvs check

Good to know.

Also with that, I deleted the architecture code within the xschem spice file before making the changes to the other spice.

In general, you'll want the low-level model description outside of the circuit, included into a testbench, perhaps. That way, the same model can be included whether your netlist is from schematic or layout, and it won't cause issues with LVS.

Good to know. Thank you for your help