https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B> I am getting some lvs errors in my ...
# magic
w
@User I am getting some lvs errors in my design which relates to the number of nets, and I think it is due to my use of deep nwell. What is the official guidance for extraction? Do I need to flatten every stage of the design so LVS passes (so I have to flatten my top level design and such)?
t
I'd have to take a look at the layout to figure out if it can extract correctly or not. If not, you might end up either "being okay" with a single LVS error that shows the ground supply split on one side and merged on the other, or do a hack solution by writing a wrapper around the schematic side that merges the grounds together so they match the extracted layout.
w
huh. actually, it looks like I might be having an issue with the poly resistor:
Copy code
Cell sky130_fd_pr__res_generic_po disconnected node: end_a
Cell sky130_fd_pr__res_generic_po disconnected node: end_b
Warning: Equate pins:  cell sky130_fd_pr__res_generic_po has no definition, treated as a black box.

Subcircuit pins:
Circuit 1: sky130_fd_pr__res_generic_po    |Circuit 2: sky130_fd_pr__res_generic_po    
-------------------------------------------|-------------------------------------------
(no matching pin)                          |1                                          
(no matching pin)                          |2                                          
---------------------------------------------------------------------------------------
Cell pin lists for sky130_fd_pr__res_generic_po and sky130_fd_pr__res_generic_po altered to match.
It seems to think that the poly resistor is disconnected or something. I am not sure what is going on. Its clearly not disconnected in the netlist
Has anyone ran this poly resistor through netgen before? Could netgen be handling it incorrectly?
I created a test with just the poly resistor and it seems to throw the same errors but passes LVS, which is weird because in the logs it talks about there being a different number of nets
Copy code
Circuit sky130_fd_pr__res_generic_po contains no devices.
Contents of circuit 1:  Circuit: 'poly_test'
Circuit poly_test contains 1 device instances.
  Class: sky130_fd_pr__res_generic_po instances:   1
Circuit contains 3 nets.
Contents of circuit 2:  Circuit: 'poly_test'
Circuit poly_test contains 1 device instances.
  Class: sky130_fd_pr__res_generic_po instances:   1
Circuit contains 2 nets.

Circuit 1 contains 1 devices, Circuit 2 contains 1 devices.
Circuit 1 contains 2 nets,    Circuit 2 contains 2 nets.

Netlists match uniquely.
Result: Circuits match uniquely.
Logging to file "comp.out" disabled
LVS Done.
@Tim Edwards there is an error in the LVS for sky130_fd_pr__res_generic_po. it seems to be adding two terminals somehow. I replaced the poly resistor with the generic resistor and it passes LVS (when previously there were two more nets)
and its not due to the subcircuit either. I instantiated the model outside of the subcircuit / tried flattening the design and it did not help
Here are two netlists that differ only in that they have the M2 resistor or poly resistor. If you pass them through netgen you will see that one is listed as having 14 nets the the other 12
power_stage.spice,power_stage_no_po.spice
power_stage.spicepower_stage_no_po.spice
Even more weird, the compare order matters
Copy code
netgen -batch lvs "mag/power_stage_lvs.spice power_stage" "xschem/power_stage.spice power_stage" $PDKPATH/libs.tech/netgen/sky130A_setup.tcl
gives 14 nets vs 12 nets. and
Copy code
netgen -batch lvs "xschem/power_stage.spice power_stage" "mag/power_stage_lvs.spice power_stage" $PDKPATH/libs.tech/netgen/sky130A_setup.tcl
gives 14 nets vs 14 nets (but neither seem to match)
(first spice is extracted for LVS, second spice is the xschem one)
power_stage.spice
t
I can't duplicate the result. From your comment about 5 posts back, I am assuming that you mean that if I compare 
power_stage
against 
power_stage_no_po
in netgen, then the cell summary will show different numbers of nets? Because I see 12 nets on each side, and it is the same regardless of the order I pass them to netgen. But I'm not sure if that's the test you ran. I only found one minor issue, which is that since a recent change I made to fix the problem with swapping pins being unnoticed by netgen, it now says "The top level cell failed pin matching" instead of "Netlists failed matching" (it never ran pin matching). But that's unrelated to your problem.
w
Huh. I made sure netgen is on the latest version. And I am getting 14 nets
was the sky130A netgen setup file recenly modified or anything?
Is there anything else I need to have up to date, because from my end things still seem terribly wrong
Looking through the logs I am seeing messages about
Copy code
Class sky130_fd_pr__res_generic_m2 does not have pin dummy_13.
Class sky130_fd_pr__res_generic_m2 does not have pin dummy_12.
and
Copy code
Cell sky130_fd_pr__res_generic_m2 disconnected node: end_a
Cell sky130_fd_pr__res_generic_m2 disconnected node: end_b
Warning: Equate pins:  cell sky130_fd_pr__res_generic_m2 has no definition, treated as a black box.

Subcircuit pins:
Circuit 1: sky130_fd_pr__res_generic_m2    |Circuit 2: sky130_fd_pr__res_generic_m2    
-------------------------------------------|-------------------------------------------
(no matching pin)                          |1                                          
(no matching pin)                          |2                                          
---------------------------------------------------------------------------------------
and if I comment the resistor out, it passes LVS
@Tim Edwards I think I have figured it out. Xschem is generating the generic_po devices with an X prefix, magic with a R prefix
which confuses the netlist matching. If I change the prefix to an R it works
Is this a xschem bug? Magic bug? netgen bug?
See these two netlists with different lines you can comment out for instantiating the resistor:
and see lines 7404 - 7409
power_stage_debug_extract.spice
t
Sorry, I was out of the house for a bit. I would call this an xschem bug, except that I believe that I reported it to Stefan and he corrected it, so either your xschem sky130 library is out of date or else I need to go pull the most recent xschem and figure out if something has changed.
w
as is, these netlists pass LVS on my end
I thought I updated that all last night. Its a bit awkard to get open_pdks to update the xschem magic stuff
the only way I could get it to install is if I ran dist-clean and rebuild all the open-pdks stuff. Is there a better way to update the sky130 magic stuff through openPDKs?
t
You can install just the tool setup parts of open_pdks by doing 
cd sky130 ; make tools-a ; sudo make install
. That avoids having to compile and install everything else.
w
Actually, looking at the timestamps in my .xschem folder it looks like the last time this folder got updated was febuary
Am I confused about the setup instructions? Should running the open_pdks setup setup the xschem libraries in .xschem?
Wait, no, that old. it should be in /usr/local/share
• /usr/share
it looks like the build instructions you provided have been updating that. but the default for the poly resistor is still spiceprefix=X
t
(1) open_pdks by default pulls the xschem sky130 library from its own repository, creating a dependency. So changes in the xschem library could impact the open_pdks install. (2) For individual project setup, I just copy the xschemrc file from sky130A/libs.tech/xschem to the local directory where I am creating a schematic. But I am not sure that that is the method that would be approved by Stefan Schippers.
It does appear that the spiceprefix is still wrong for the poly resistor. As I said, though, I will do a review and get in touch with Stefan on any outstanding items.
w
This is an easy fix, I just need to change that manually
I was also getting a bit confused by the old sky130 library stuff in the .xschem/ I should purge that.
The sky130_fd_pr__res_generic_m1 resistor (which by renaming can be the other generic resistors) also defaults to X and still has the multi parameter, which causes simulation issues
3 Views
Open in Slack
PreviousNext
Powered by