Hello <@U017X0NM2E7> <@U016EM8L91B> i am trying to...
# lvs
r
Hello @Mitch Bailey @Tim Edwards i am trying to run the lvs but its getting crash could you please let me know how to fix it
t
Your screenshot shows a netlist 1T1R_2x2_xschem.spice that you did not post. Also your screenshot shows a netlist 1T1R_2x2.spice while you posted 1T1R_2x2_2.spice; I don't know how these relate to each other.
Most likely the crash condition comes from the control block or the model in your netlist. A netlist for LVS should not contain these elements.
However, I do understand that netgen should be able to deal with them, so I will try to debug the problem accordingly.
r
i have attach the screen shot i was trying to run the files with random and check about crash for the posted xschem and layout spice its crashing do i need to remove the elements of reram from xschem i generated the netlist from xschem
@Tim Edwards thank you for looking in the problem
t
The error itself will probably take some time to track down. It is rather mysterious in origin. However, it originates from passing a mismatched set of cells to netgen, so it is probably easier just to avoid the segfault error by correcting the error in calling netgen. When generating a netlist from xschem, you need to set
Simulation-->LVS-->LVS netlist:  Top level is a .subckt
. Then you will have a top level subcircuit in both netlists that you can compare directly. After generating the correct netlist from schematic, call netgen with
netgen -batch lvs "1T1R_2x2_2.spice 1T1R_2x2" "oneTtwoR_2x2arrayfinal.spice oneTtwoR_2x2arrayfinal"
. That is, for each circuit specify both the filename and the cellname of the cell you want to compare.
r
@Tim Edwards thank you I follow your instruction and try to run netgen thank you
@Tim Edwards i have the question that when i used the schematic instead of symbol devices where not recognised when i used the symbol it worked and lvs passed why do we need to use the symbols?
t
I'm not exactly sure what you mean by that, and I would have to look at both result files to say why one is passing LVS and the other isn't. Make sure that it really is passing by checking everything down to the transistor level and not treating the symbols as "black boxes".
r
Hello @Tim Edwards for now i have terminal screenshot i can share the results of both by tomorrow morning from the terminal i guess reram cell is being consider as blackbox
m
@Rafeeq Khan Mohammed reram as a black box is correct.
r
@Tim Edwards I have attached the fail and pass lvs could you please look and let me know thank you
@Tim Edwards I have attached the schematic spice file with symbol generated which passed LVS, and the other without symbol which lvs fail but i can see in the output file 5v transistor also being used as black box i am including the layout spice file also
@Tim Edwards .
m
In the failing LVS, the schematic has
sky130_fd_pr_reram__reram_cell
while the extracted layout has
sky130_fd_pr__reram_reram_cell
. These need to be the same. When sharing LVS results, please share the LVS command(s) too.
r
@Mitch Bailey i have use the following lvs commands 1.fail one netgen -batch lvs "1T1R_2x2.spice 1T1R_2x2" "oneTtwoR_2x2arrayfinal_layout.spice oneTtwoR_2x2arrayfinal_layout" 2. pass one netgen -batch lvs "1T1R_2x2_symbol.spice 1T1R_2x2_symbol" "oneTtwoR_2x2arrayfinal_layout.spice oneTtwoR_2x2arrayfinal_layout" how do i fix the reram as blackbox ? i mean how do i change the name do i need to change in sym files
for now i just edited the name in the file and run to just check now 5v devices are been considered as black box
m
@Rafeeq Khan Mohammed The schematic netlist has
Copy code
XR1 bl2 net1 sky130_fd_pr_reram__reram_cell Tfilament_0=3.8e-9
XR2 bl2 net4 sky130_fd_pr_reram__reram_cell Tfilament_0=3.8e-9
XR3 bl1 net3 sky130_fd_pr_reram__reram_cell Tfilament_0=3.8e-9
XR4 bl1 net2 sky130_fd_pr_reram__reram_cell Tfilament_0=3.8e-9
but
sky130_fd_pr_reram__reram_cell
is not defined anywhere. The layout netlist has
sky130_fd_pr__reram_reram_cell
as an undefined circuit, but the schematic has this as a defined circuit. You may be encountering problems by using the same netlist for simulation and LVS. I believe the best practice is to create the LVS schematic (no code, lib, or includes) and then instantiate that in a testbench that has the simulation settings.
r
@Mitch Bailey I did the same way you said no code and lib I included while generating the netlist that all included from reram osdi I guess
m
Does the xschem library have a
sky130_fd_pr__reram_reram_cell
symbol (as opposed to the current
sky130_fd_pr_reram__reram_cell
) ?
r
@Mitch Bailey it's not there in xschem library But in home/tools/open_pdks/sky130B/libs.tech/xschem/sky130_fd_pr There is reram.sym in that sky130_fd_pr_reram__reram__cell is written
sorry
i fixed it but 5v transistor is treated as black box
i am sharing files now
setup.tcl,1T1R_2x2 (1).spice,comp.out,oneTtwoR_2x2arrayfinal.spice
netgen -batch lvs "1T1R_2x2.spice 1T1R_2x2" "oneTtwoR_2x2arrayfinal_layout.spice oneTtwoR_2x2arrayfinal_layout"
m
Not sure of the best way to handle this. The xschem symbol instance has these properties.
Copy code
name=R1 model=sky130_fd_pr_reram__reram_cell spiceprefix=X Tfilament_0=3.8e-9
The model name does not match the extracted device name. Changing that would probably be a first step. The symbol itself has a lot more properties that aren’t necessary for lvs. I wonder if adding
lvs_format
property would resolve this. Primitive devices such as
sky130_fd_pr__nfet_g5v0d10v5
should be treated as black boxes.
r
@Mitch Bailey thank you so much I will follow your instructions to fix I hope it should fix
@Mitch Bailey what do you mean by adding lvs_property should i remove the extra properties delete it as per the lvs format ?
@Mitch Bailey i have done it now what i did is i change the model name and also remove the extra properties in the spice file for lvs which i attacted the two screenshots hope now its correctly passing lvs..?
m
@Rafeeq Khan Mohammed congratulations! Ideally, LVS should pass without size errors, but I don’t have any advice on how to get rid of those at the moment.
r
@Mitch Bailey thank you so much
@Mitch Bailey @Tim Edwards Hi there! Could you please check my results and let me know if they are correct or incorrect? During the setup.tcl file I encountered a naming issue for cell i. I renamed the property which helped me to get over the tfilament property error. However, the area_ox also showed up as a property error. To solve this, I added the same line as tfilament delete instead of tfilament area_ox (as shown in the screenshot). After doing this, it passed without any property errors. Is this the correct way to solve this issue? but reram is getting as blackbox until now in the whole process reram has been considered as blackbox only
m
@Rafeeq Khan Mohammed I think you have a valid solution. It may be a while before your solution is integrated into the pdk.
r
@Mitch Bailey what about reram is being considered as Blackbox? Is it okay to be get considered sky130_fd_pr_reram
m
For LVS, reram is extracted with this command
Copy code
device csubcircuit sky130_fd_pr__reram_reram_cell reram m1 a=area_ox
which creates an X prefixed device in the netlist (mosfets are also netlisted as X devices). So for LVS,
sky130_fd_pr__reram_reram_cell
is the base device. For simulation, it is possible to add a subcircuit definition for
sky130_fd_pr__reram_reram_cell
that instantiates a simulatable model. Maybe you can ask about specifics on the #reram channel for people who’ve worked on a reram design.
r
Okay I will ask @Mitch Bailey thank you