LDO Pull Request

[akiles-esta-usado]

Schematics and a preliminary area estimation of LDO. Python files were tested in another environment and might not work in the proposed one

[d-mitch-bailey]

Looking at the references in your schematics, I see some absolute paths and references to the wrong PDK (gf180mcuC instead of gf180mcuD). These make the design effectively unreadable by anyone who does not have the exact same environment.

Preamp-Strong-Latch.sch:C {../spice/SR_nor.sym} 2530 -1620 0 0 {name=X1}
Preamp-Strong-Latch.sch:C {../spice/preamp.sym} 3760 -2920 0 0 {name=X3}
Preamp-Strong-Latch.sch:C {../spice/strongarm.sym} 2570 -1890 0 0 {name=X4}
Preamp-Strong-Latch.sch:.include /foss/pdks/gf180mcuC/libs.tech/ngspice/design.ngspice
Preamp-Strong-Latch.sch:.lib /foss/pdks/gf180mcuC/libs.tech/ngspice/sm141064.ngspice typical
SR_nand.sch:C {/foss/pdks/gf180mcuC/libs.tech/xschem/symbols/pfet_03v3.sym} 2000 -2020 0 0 {name=M1
SR_nand.sch:C {/foss/pdks/gf180mcuC/libs.tech/xschem/symbols/nfet_03v3.sym} 2140 -1860 0 1 {name=M2
...
bootstrap_sw.sch:C {/foss/designs/sar_adc/xschem/spice/inv.sym} 110 30 0 0 {name=x2}
bootstrap_sw.sch:C {/foss/designs/sar_adc/xschem/spice/inv.sym} -180 -280 0 0 {name=x3}
bootstrap_sw.sch:C {/foss/pdks/gf180mcuC/libs.tech/xschem/symbols/nfet_03v3.sym} 210 -80 3 0 {name=M3
bootstrap_sw.sch:C {/foss/pdks/gf180mcuC/libs.tech/xschem/symbols/nfet_03v3.sym} 230 60 2 0 {name=M6
...
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 80 -90 0 0 {name=x1
cdac.sch:C {../spice/cdac_line.sym} 210 -90 0 0 {name=x2
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 340 -90 0 0 {name=x3
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 470 -90 0 0 {name=x4
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 600 -90 0 0 {name=x5
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 730 -90 0 0 {name=x6
cdac.sch:C {/foss/pdks/gf180mcuC/libs.tech/xschem/symbols/cap_mim_2p0fF.sym} 840 -160 1 0 {name=CA
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 910 -90 0 0 {name=x7
cdac.sch:C {/foss/designs/sar_adc/xschem/spice/cdac_line.sym} 1040 -90 0 0 {name=x8
...

You can create an xschemrc file in the spice directory to make things more portable.
Try using this template.
Set export PDKPATH=$PDK_ROOT/$PDK in the shell and then open and save your designs to convert everything to relative references so that other people can view the designs.

[akiles-esta-usado]

Hi, I'm not sure if those files are from our LDO, it seems that they are from a SAR ADC.

[d-mitch-bailey]

There may be a problem with the npn layout. I think the NWEL layer is missing. Was this generated as a magic device?

@RTimothyEdwards I don't know if you have anything to do with the npn device generators for magic in gf180mcu, but I think the NWEL that connects the N-diffusion to deep nwell is missing.

[d-mitch-bailey]

@akiles-esta-usado I did not list all the files with absolute references - only a sample.

You can check the schematic/symbol files that you are responsible for to verify that they do not have absolute references. You might also consider adding a xschemrc file to the repo as suggested that will allow others to open the designs in their environments. There is an xschemrc file, but it appears to have sky130 references.

[d-mitch-bailey]

@akiles-esta-usado You are correct. Looks like I was looking at the SAR-ADC project. Sorry.
Looking at your schematics, it appears that most of the references are relative. I did see one absolute reference in LDO/xschem/ldo_gf180.sch though.

C {/foss/pdks/gf180mcuC/libs.tech/xschem/symbols/pfet_03v3.sym} 1130 -500 0 0 {name=M0
L=0.7u
W=1000u
nf=11
m=1
ad="'int((nf+1)/2) * W/nf * 0.18u'"
pd="'2*int((nf+1)/2) * (W/nf + 0.18u)'"
as="'int((nf+2)/2) * W/nf * 0.18u'"
ps="'2*int((nf+2)/2) * (W/nf + 0.18u)'"
nrd="'0.18u / W'" nrs="'0.18u / W'"
sa=0 sb=0 sd=0
model=pfet_03v3
spiceprefix=X
}

I also saw some absolute references for ngspice files included for simulation. You might want to fix those. Most are correct, though.

[RTimothyEdwards]

I wish to strongly reiterate that the GF tech file for magic has only been used with digital circuits and the GF padframe I/O and the DRC, extraction, and analog device generators have only been lightly tested. Because the original intent of the GFMPW-1 tapeout was to be another digital-only shuttle run like GFMPW-0, it took me a bit by surprise to find that people were doing analog designs with the tech file. I had hoped to give the tech file and device generator scripts a thorough testing over the summer, but that never happened. Any help with checking and correcting the DRC rules in magic and checking and correcting the device generator Tcl scripts would be greatly appreciated.