search

RTimothyEdwards / magic

Magic VLSI Layout Tool
Other
498 stars 103 forks source link

Bulk connection not extracting correctly for nmos #106

Open d-m-bailey opened 2 years ago

d-m-bailey commented 2 years ago

The bulk connections for some nmos are not extracting correctly. This sample is from the sky130_sram_macros repo. There is no port for sky130_sram_1kbyte_1rw1r_32x256_8_contact_16_0/gnd so it is isolated in this subckt.

.subckt sky130_sram_1kbyte_1rw1r_32x256_8_pnand2 Z gnd vdd A B w_n36_538#
X0 a_144_51# A gnd sky130_sram_1kbyte_1rw1r_32x256_8_contact_16_0/gnd sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=740000u l=150000u
X1 vdd B Z w_n36_538# sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.12e+06u l=150000u
X2 Z A vdd w_n36_538# sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.12e+06u l=150000u
X3 Z B a_144_51# sky130_sram_1kbyte_1rw1r_32x256_8_contact_16_0/gnd sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=740000u l=150000u
.ends

I've created a relatively minimal test case.

sram_nmos_bulk.tar.gz

RTimothyEdwards commented 2 years ago

Thanks. I think this is the same issue that has been reported in the past by Matt Guthaus. Please check if it is solved by using the option "extract do labelcheck", but I think this was something else.

RTimothyEdwards commented 2 years ago

Okay, I just read through the discussion on the skywater-pdk slack channel and this must be something different, some unintended consequence of a recent code change. I'll look into it. Thanks for the example file.

RTimothyEdwards commented 2 years ago

@d-m-bailey : I just pushed an update (magic version 8.3.235 on opencircuitdesign.com) that should fix this issue.

d-m-bailey commented 2 years ago

@RTimothyEdwards The fix works in one of the test cases I sent, but not the other. run_ext_flat.sh appears to work fine but with the run_ext_cell.sh script, these are the changes I see.

*** sky130_sram_1kbyte_1rw1r_32x256_8_pand2.cell.spice.233  2021-11-30 17:31:26.625730752 -0800
--- sky130_sram_1kbyte_1rw1r_32x256_8_pand2.cell.spice  2021-12-03 03:19:17.647329756 -0800
***************
*** 27,40 ****
  .ends

  .subckt sky130_sram_1kbyte_1rw1r_32x256_8_pmos_m2_w1_260_sli_dli_da_p S D G S_uq0
! + w_n59_42#
  X0 D G S w_n59_42# sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
  X1 S_uq0 G D w_n59_42# sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
  .ends

  .subckt sky130_sram_1kbyte_1rw1r_32x256_8_pinv A Z gnd vdd
  Xsky130_sram_1kbyte_1rw1r_32x256_8_nmos_m2_w0_740_sli_dli_da_p_0 gnd Z A gnd sky130_sram_1kbyte_1rw1r_32x256_8_nmos_m2_w0_740_sli_dli_da_p
! Xsky130_sram_1kbyte_1rw1r_32x256_8_pmos_m2_w1_260_sli_dli_da_p_0 vdd Z A vdd vdd sky130_sram_1kbyte_1rw1r_32x256_8_pmos_m2_w1_260_sli_dli_da_p
  .ends

  .subckt sky130_sram_1kbyte_1rw1r_32x256_8_pdriver Z A gnd vdd
--- 27,41 ----
  .ends

  .subckt sky130_sram_1kbyte_1rw1r_32x256_8_pmos_m2_w1_260_sli_dli_da_p S D G S_uq0
! + w_n59_42# gnd
  X0 D G S w_n59_42# sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
  X1 S_uq0 G D w_n59_42# sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
  .ends

  .subckt sky130_sram_1kbyte_1rw1r_32x256_8_pinv A Z gnd vdd
  Xsky130_sram_1kbyte_1rw1r_32x256_8_nmos_m2_w0_740_sli_dli_da_p_0 gnd Z A gnd sky130_sram_1kbyte_1rw1r_32x256_8_nmos_m2_w0_740_sli_dli_da_p
! Xsky130_sram_1kbyte_1rw1r_32x256_8_pmos_m2_w1_260_sli_dli_da_p_0 vdd Z A vdd vdd gnd
! + sky130_sram_1kbyte_1rw1r_32x256_8_pmos_m2_w1_260_sli_dli_da_p
  .ends

  .subckt sky130_sram_1kbyte_1rw1r_32x256_8_pdriver Z A gnd vdd

An unconnected gnd port has been added to the pmos. The nmos bulks remain unconnected.

.subckt sky130_sram_1kbyte_1rw1r_32x256_8_nmos_m1_w0_740_sli_dactive S G a_90_0#
X0 a_90_0# G S w_n26_n26# sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=740000u l=150000u
.ends

.subckt sky130_sram_1kbyte_1rw1r_32x256_8_nmos_m1_w0_740_sactive_dli D G a_0_0#
X0 D G a_0_0# w_n26_n26# sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=740000u l=150000u
.ends
RTimothyEdwards commented 2 years ago

@d-m-bailey : Okay, I backed up to where the issue started showing up in revision 214 and figured out why the change made in revision 214 was incorrectly done. I have just pushed a fix that undoes pretty much all of the changes I made yesterday and instead implements the method intended for revision 214 correctly.

d-m-bailey commented 2 years ago

@RTimothyEdwards Tried magic 8.6.236, but getting duplicate ports. :[ Using the test case I sent the other day (see the top of the thread), 

./run_ext.sh sky130_fd_bd_sram__openram_sense_amp

It gives the following

* NGSPICE file created from sky130_fd_bd_sram__openram_sense_amp.ext - technology: sky130A

.subckt sky130_fd_bd_sram__openram_sense_amp bl br dout en vdd VDD_uq0 GND_uq0 GND_uq0
+ vdd
X0 a_154_1298# a_96_1689# vdd vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
X1 GND_uq0 en a_184_1689# GND_uq0 sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X2 a_154_1298# a_96_1689# a_184_1689# GND_uq0 sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X3 GND_uq0 a_154_1298# dout GND_uq0 sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X4 bl en a_96_1689# vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=2e+06u l=150000u
X5 a_154_1298# en br vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=2e+06u l=150000u
X6 vdd a_154_1298# a_96_1689# vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
X7 a_184_1689# a_154_1298# a_96_1689# GND_uq0 sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X8 VDD_uq0 a_154_1298# dout vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
.ends

Two GND_uq0 nets and two vdd ports.

RTimothyEdwards commented 2 years ago

@d-m-bailey : The OpenRAM layout is just chock full of pathological cases. I guess it's just part of being a very large, complicated, and real-world design. It catches a lot of things I don't see in simple test cases. In this case, there are two things to note: (1) There really are two "vdd" ports, which are two nets labeled "vdd", one of which is tied to the nwell and one which isn't, so that part of the extraction is correct. (2) There are two nets labeled "gnd", both of which are tied to substrate but which are not connected by metal, therefore forming a "soft" connection. Because the extraction engine merges all soft connections, the "extract unique" should not be generating unique names for different parts of the net. Once it has done that, though, the extraction gets confused because it sees two different ports for what it sees as the same net. I think the solution here is to prevent "extract unique" from generating new names on soft connections.

RTimothyEdwards commented 2 years ago

@d-m-bailey : I just pushed an update that forces "extract unique" to ignore soft substrate connections, which should resolve the issue above. I'm not sure what, if anything, this has to do with the repeated "vdd" port, though. When I ran I only got three ports, for "GND", "VDD", and "vdd_uq0". The layout has the weird property that all labels are repeated, once in lowercase with a point label, and once in uppercase with a rectangular label, with different port numbers . This could also cause weird behavior with "extract unique" and "extract". It is not exactly proper to provide two port names with two different port numbers for the same net.

d-m-bailey commented 2 years ago

@RTimothyEdwards I appreciate the quick response. Unfortunately, it still looks like there are duplicate ports. If the mag files are still around, you can run the previously mentioned test case

./run_ext.sh sky130_fd_bd_sram__openram_sense_amp

and now get

* NGSPICE file created from sky130_fd_bd_sram__openram_sense_amp.ext - technology: sky130A

.subckt sky130_fd_bd_sram__openram_sense_amp bl br dout en vdd gnd VDD_uq0 gnd vdd
X0 a_154_1298# a_96_1689# vdd vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
X1 gnd en a_184_1689# gnd sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X2 a_154_1298# a_96_1689# a_184_1689# gnd sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X3 gnd a_154_1298# dout gnd sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X4 bl en a_96_1689# vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=2e+06u l=150000u
X5 a_154_1298# en br vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=2e+06u l=150000u
X6 vdd a_154_1298# a_96_1689# vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
X7 a_184_1689# a_154_1298# a_96_1689# gnd sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
X8 VDD_uq0 a_154_1298# dout vdd sky130_fd_pr__pfet_01v8 ad=0p pd=0u as=0p ps=0u w=1.26e+06u l=150000u
.ends
RTimothyEdwards commented 2 years ago

@d-m-bailey : I swear this worked yesterday. But I had pulled out the sense amp and was working with that layout directly, which must somehow account for the difference. I ran with the script just now and get the same result you do. Please stand by while I go bang my head against the wall.

RTimothyEdwards commented 2 years ago

@d-m-bailey : Okay, I pushed one more fix. I ran your extraction script and also checked the extraction both for the sense amp itself, and then extracted the SRAM from the top and checked both the sense amp subcircuit and the instances of it, and all of it looked correct to me.

d-m-bailey commented 2 years ago

@RTimothyEdwards the problem of unconnected nmos bias appears to be fixed with the magic 8.3.238. I intend to do regression tests with the mpw-2 chips this week.