https://open-source-silicon.dev logo
Channels
aa
abcc
activity
adiabatonauts
analog-design
announce
announcements
b2aws
b2aws-tutorial
bag
basebands
beagleboard
bluetooth
board-respin
cadence-genus
cadence-innovus
cadence-spectre
cadence-virtuoso
caravan
caravel
caravel-board
chilechipmakers
chip-yard
chipignite
chipignite2206q_stanford_bringup
chisel
coalition-for-digital-environmental-sustainability
community_denmark_dtu
containers
courses
design-review
design-services
dffram
digital-design
digital-electronics-learners
discord-mods
dynamic-power-estimation
efabless
electric
events
fasoc
fault
foss-asic-tools
fossee-iitb-esim
fossee-iitb-google-sky130
fpga
funding
fuserisc
general
generative-ai-silicon-challenge
genius-vlsi
gf180
gf180mcu
hardware-beginners
help-
ieee-sscs-cac-23
ieee-sscs-dc-21q3
ieee-sscs-dc-22
ieee-sscs-dc-23
ihp-sg13g2
images
infiniband
j-core
japan-region
junk
klayout
latam_vlsi
layouteditor
lvs
lvs-analysis
magic
magical
maker-projects
maker-zone
microwatt
mpw-2-silicon
mpw-one-clean-short
mpw-one-silicon
neuro-mem
nydesign
open_pdks
open-pdk
openadiabaticlogic
openfpga
openhighqualityresonators
openlane
openlane_cloudrunner
openlane-development
openocd
openpositarithmetic
openpower
openram
openroad
opentitan
osu
pa-test-chip
paracells
pd-openlane-and-sky130
picosoc
pll
popy_neel
power
private-shuttle
rad-lab-silicon
radio
rdircd
reram
researchers
rf-mmw-design
rios
riscv
sdram
serdes
shuttle
shuttle-precheck
shuttle-status
silicon-photonics
silicon-validation
silicon-validation-private
sky130
sky130-ci
sky130-pv-workshop
sky65
sky90
skywater
sram
stdcelllib
strive
swerv
system-verilog-learners
tapeout-job
tapeout-pakistan
team-awesome
timing-closure
toysram
travis-ci
uvm-learners
vendor-synopsys
venn
verification-be
verification-fe
verilog-learners
vh2v
vhdl
vhdl-learners
vliw
vlsi_verilog_using_opensource_eda
vlsi_verilog_using_opensoure_eda
vlsi-learners-group
vlsi101
waveform-viewers
xls
xschem
xyce
zettascale
Powered by
Title
a

Antony Brayan Sanabria Calderón

04/05/2023, 11:27 PM
Hello everyone, I have a question about the layout of a ring oscillator whose frequency is controlled by varactors. When performing the LVS, I get a message indicating that the netlists don't match. Reviewing the file that is generated (comp.out), I have noticed that there seems to be no match in the bulks of the MOSFETs. Does anyone know if this is true or if I'm misinterpreting? I appreciate help. I'm attaching images of the layout, the circuit in Xschem, the message displayed in the console and the comp.out file.
m

Mitch Bailey

04/06/2023, 12:30 AM
@Antony Brayan Sanabria Calderón You’re interpretation of the results is correct. Do you have Nwell and Psubstrate taps in the layout? The Nwell for the pfets should be connected to vdd and the psubstrate tied to vss. Could you also post your extracted netlist and the netlist generated from the schematic. I’m not used to seeing labeled terminals on the mosfets. That may be causing problems too. Also, there was a discussion on slack a few days ago about the merits of connecting both diffusion terminals of the varactors for better performance.
t

Tim Edwards

04/06/2023, 12:45 AM
@Antony Brayan Sanabria Calderón: Circuit 2 (the schematic) is reporting pins "gate source drain bulk" which means that the schematic is using "M" as the SPICE prefix for the device. The devices are all modeled as subcircuits, so Magic will extract them with the "X" prefix. The schematic has to declare each of the devices to be a subcircuit, as well.
m

Mitch Bailey

04/06/2023, 12:53 AM
@Tim Edwards Do you know if exporting mosfets as subcircuits is an option in xschem? I thought it was the default.
t

Tim Edwards

04/06/2023, 12:59 AM
@Mitch Bailey: Like everything in xschem, if you want to change it, you just edit the text in the properties menu. The xschem library should be set up to write them as subcircuits by default, but I think commercial tools regularly convert to the base SPICE types for LVS, so people may be used to doing that, not realizing that netgen is set up to run LVS on the same netlist used for simulation.
👍 1
s

Stefan Schippers

04/06/2023, 9:07 AM
@Mitch Bailey the sky130 MOS components are netlisted as subcircuits because spice models describe these devices as subcircuits. Xschem adds a
spiceprefix
character
X
to the instance name (M12 --> XM12). This can be changed by disabling menu `Simulation -> Use spiceprefix attribute`'
a

Antony Brayan Sanabria Calderón

04/06/2023, 5:04 PM
Hello everyone, thank you very much for your help. It helped me a lot to understand the problem. After reading your comments, I decided to go into the generated .spice and found that nets names and device names were different. In a simpler circuit, I verified that the difference in the nets names doesn't generate any problems. I then decided to manually change the device names and, when performing the LVS, the console message mentions that there is a spice match. I don't know how to get Magic to generate a spice with the correct device names. Because it generate names like (X#). I attach an image of the console message when doing the LVS.
Below is an imagen of the before and after comparison, thanks a lot.
t

Tim Edwards

04/06/2023, 9:36 PM
@Antony Brayan Sanabria Calderón: The device names starting with "X" (i.e., subcircuits) are correct for this technology. You need to change the option in xschem where you are disabling the SPICE prefix (see Stefan's comment above), so that xschem will also produce device names beginning with "X".