https://open-source-silicon.dev logo
Join Slack
Powered by
comp.out,ldo_amp_dp.spice,ldo_amp_dp_ext.spice
# magic
t
comp.out,ldo_amp_dp.spice,ldo_amp_dp_ext.spice
ldo_amp_dp.spiceldo_amp_dp_ext.spicecomp.out
m
What commands are you using for extraction and LVS? magic extracts transistors as X devices and unless you're using the necessary netgen setup file, it may ignore them. I noticed what appear to be parasitic capacitors in your extracted netlist. This is fine for simulation, but probably not what you what for LVS.
t
@Mitch Bailey I was following this tutorial but using my netlists instead. I realized after I posted that I prob wouldn't want the pcaps actually but since the devices aren't being found I need to solve that anyway, thanks for pointing that out though. The command I'm using is 
netgen lvs ldo_amp_dp.ext.spice ldo_amp_dp.spice
m
The LVS flow for openlane uses the following settings when extracting the layout.
Copy code
extract do local
extract no capacitance
extract no coupling
extract no resistance
extract no adjust
extract unique noports
extract
ext2spice lvs
LVS uses 
sky130A/libs.tech/netgen/sky130A_setup.tcl
so maybe add that at the end of your netgen command.
t
@Mitch Bailey thanks, I'll give that a try. Do you know why I don't get any parasitic resistors in my extracted netlist when doing PEX with 
ext2spice rthresh 0
? as you pointed out I get pcap but no pres
m
Sorry, I have no experience with PEX.
t
ok, thanks anyway
t
@Tom: Parasitic resistances are complicated to do and require running "extresist" in magic. Also they don't work quite right at the moment because they depend on the .sim format which has no concept of substrate; consequently there's a round of search-and-replace that has to be done on the final netlist. I'll be working on that problem between shuttle runs.
@Tom: As for the LVS: You don't run LVS on a parasitic extracted netlist. But the main problem here is that you need the netgen setup file for the sky130A process, or else it doesn't know what the low level devices are. Specify the "sky130A_setup.tcl" file from open_pdks as the setup file, it should work.
t
Thank you @Tim Edwards, It seems to be running as expected now, but I have a mismatch involving 
VSUBS
. My schematic ties the FET bulk contacts to 
vss
(picture below) and my layout labels the guard ring as 
vss
too. I thought the guard ring served as my tap into well forming my bulk contact so I don't understand the mismatch and the presence of the extra net. Is that not right?
comp.out
ldo_amp_dp.mag
t
I have not added my indended method that would let magic regenerate the parameterized cell from the properties (which requires saving the properties in the output file), so I need the file 
sky130_fd_pr__nfet_g5v0d10v5_N76Z7G.mag
to go along with the top level.
t
@Tim Edwards oops sorry, I forgot to attach that. Here it is. Thanks for taking a look.
sky130_fd_pr__nfet_g5v0d10v5_N76Z7G.mag
t
All right, this is a problem in magic and I need to do something about it. It won't automatically infer a connection from the substrate in the top level to the pwell layer in the subcell. To get it to work right, just paint the left side guard ring contact on top of itself on the top level layout. That will form the connection between vss and the substrate on the top level cell, and the issue will go away. But I still need to fix it in the code. . .
t
Ah brilliant, ok thank you, Tim. I'll give that a try.
t
My word for it isn't "brilliant", but "an atrocious hack". But it'll get the job done for now.
t
haha, sure
Wait sorry, @Tim Edwards, which layer do I want to paint on top of the contact?
as in the name
t
The contact type is "mvpsc" for short.
Or "mvpsubdiffcont" for long.
t
ok cheers
Yup, that worked @Tim Edwards. Thanks for the help!
@Tim Edwards just out of interest, do you know how everyone else has been dealing with this problem? Have you heard of others with the same issue or do you suspect they all just paint as you suggested?
t
Not sure. I'm not even sure if this might be something that cropped up recently due to a code change. I found it surprising, as I don't recall having issues with the substrate connection in a simple analog circuit like that.
t
I see
t
The challenge of making the tools work with a brand new PDK is that they tend to get fragile for a while until all the kinks are ironed out.
If the PDK were a bit more standard, then these issues would be a lot fewer.
t
Right. Where should I look out for news on a new release of magic which propagates the substrate connection?
t
I can announce it in the #magic channel, as well as pinging you specifically about it.
t
Thank you!
@Tim Edwards I've run LVS on a larger (still small) design now but it's complaining that the layout contains instances of 
sky130_fd_pr__pfet_20v0
which do not exist in the schematic. I've grep'ed the layout folder for all instances of 
pfet
in 
*.mag
files and only see instances of the intended 
sky130_fd_pr__pfet_g5v0d10v5
FETs so I'm not sure whats going on. Have you seen anything like that before? I've attached the report and layout files, along with the netlists in the event you get a chance to look.
lvs_report.logldo_layout.zipldo_amp_lvsmag.spiceldo_amp_flat.magldo_amp_lvssch.spice
Just to be clear this is happening when running lvs on the 
ldo_amp
I've not got to the 
ldo_top
yet
t
Yes, I have seen this before but I thought I got rid of it with an update to magic, or the tech file, or possibly both. The 20V pFET looks essentially like a 5V pFET but with an extended drain, so the way magic detects them is very similar. One has poly with diffusion on both sides, and the other has poly with diffusion on only one side. There are still some ways to trick magic into thinking it doesn't see the diffusion on one side. I'll take a look at the layout and let you know.
This does look like the same problem: A source-drain tied FET looks like a 1-terminal device, which tricks magic into thinking it's a 20V device. I did fix this behavior, so it should go away if you update your version of magic.
t
Ah interesting. Ok, thanks, @Tim Edwards I'll do that and give it another try.
t
The issue was fixed in magic version 8.3.103.
t
That worked! Thanks @Tim Edwards I'll try to remember to make sure I've got the latest version next time I run into issues
@Tim Edwards I've been trying to get my LVS script to flatten the hierarchy in order to get around the diffusion contact issue you alerted me to yesterday, so I've modified the 
*.tcl
generation part of the bash script to do the following:
Copy code
# create magic tcl script
echo "load $MAG_FILE
flatten -nolabels flat.mag
writeall force
load flat.mag
extract all
ext2spice lvs
ext2spice -o $2_lvsmag.spice
exit" > extract_lvs.tcl

# invoke magic for lvs spice netlist extraction
magic -rcfile $PDK_ROOT/sky130A/libs.tech/magic/sky130A.magicrc -noconsole -dnull extract_lvs.tcl &
but it doesn't seem to produce the flattened cell whatever I do (I'd also rather not have to 
writeall
if it can be avoided. These commands work fine if I execute them from the console, and all the other parts of the tcl script work too.
I'm running Magic 8.3.110 too btw
lvs.sh
lvs.sh
t
You are likely running into an issue by tagging ".mag" to the end of a cell name. The places you are using that are calling for cell names, not file names. So use "flatten -nolabels flat" and "load flat"
A slightly less roundabout way of writing the script is just "magic -rcfile ... -dnull << EOF" followed by the script and followed by "EOF"; doesn't involve an extra file in the middle.
t
Thanks @Tim Edwards looks like the 
.mag
was the issue after all. I also managed to get rid of the 
writeall
too since presumably the flattened cell is lust loaded directly from the buffer without having save it to disk.
6 Views
Open in Slack
PreviousNext
Powered by