can LVPWELL be used without DNWELL?

[proppy]

Looking at the current pcells, it seems that drawing the LVPWELL for nfet:

globalfoundries-pdk-libs-gf180mcu_fd_pr/cells/klayout/pymacros/cells/draw_mos.py

Lines 192 to 195 in 11770e5

	# Inserting LVPWELL
	cell.shapes(lvpwell).insert(pya.Box(-lvpwell_enc_pcmp-cmp2cmp-ld, -lvpwell_enc_ncmp,
	(2 * (ld + ld_violat) + l + lvpwell_enc_ncmp + (nf - 1) * (ld + ld_violat + l + cont2ply - cmp2cont)),
	w + lvpwell_enc_ncmp))

is gated by having deepnwell param enabled:

globalfoundries-pdk-libs-gf180mcu_fd_pr/cells/klayout/pymacros/cells/draw_mos.py

Line 172 in 11770e5

if deepnwell == True:

Are those two always tied together? looking at the design manual there seems to be a valid use case for using LVPWELL outside of DNWELL:
https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_04.html

If this layer is used without DNWELL (outside DNWELL), the body of all those transistors will by default be connected to P-substrate potential.

@atorkmabrains @RTimothyEdwards

[RTimothyEdwards]

@proppy : Yes, LVPWELL outside of DNWELL is equivalent to substrate and should be treated as such. That usage is in much of the GF IP.

[atorkmabrains]

Thanks @RTimothyEdwards

[proppy]

@RTimothyEdwards Thanks for the explanation.

@atorkmabrains would it makes sense to update the pcells to always draw LVPWELL when Bulk Tie is set?

globalfoundries-pdk-libs-gf180mcu_fd_pr/cells/klayout/pymacros/cells/draw_mos.py

Lines 192 to 195 in 11770e5

	# Inserting LVPWELL
	cell.shapes(lvpwell).insert(pya.Box(-lvpwell_enc_pcmp-cmp2cmp-ld, -lvpwell_enc_ncmp,
	(2 * (ld + ld_violat) + l + lvpwell_enc_ncmp + (nf - 1) * (ld + ld_violat + l + cont2ply - cmp2cont)),
	w + lvpwell_enc_ncmp))

[spnadig]

@msaligane - this was the issue I was talking about - We had to add Deep N well as a fix to pass LVS because the bulk pin would not get connected appropriately if DN WELL was not enabled

[proppy]

@atorkmabrains currently it seems that LVPWELL is only drawn when DNWELL is set in the pcell option, would it make sense to update the pcell implementation to always draw LVPWELL when bulk tie is enabled independently of the state of the DNWELL option?

[atorkmabrains]

@proppy That's a separate issue. LVPWELL is optional or don't care in case that DNWELL is not drawn. If you draw, DNWELL you can draw LVPWELL. Pcell is functioning correctly, no need to add this modification into the pcell.

@spnadig Could you please show me the design that caused this?

I advise that you use DRC and LVS from https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr? Also, please stay tuned as we are going to move LVS and DRC to: https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pv.

cc @msaligane

[atorkmabrains]

@RTimothyEdwards Thanks for the explanation.

@atorkmabrains would it makes sense to update the pcells to always draw LVPWELL when Bulk Tie is set?

globalfoundries-pdk-libs-gf180mcu_fd_pr/cells/klayout/pymacros/cells/draw_mos.py

Lines 192 to 195 in 11770e5

	# Inserting LVPWELL
	cell.shapes(lvpwell).insert(pya.Box(-lvpwell_enc_pcmp-cmp2cmp-ld, -lvpwell_enc_ncmp,
	(2 * (ld + ld_violat) + l + lvpwell_enc_ncmp + (nf - 1) * (ld + ld_violat + l + cont2ply - cmp2cont)),
	w + lvpwell_enc_ncmp))

@proppy No, as I mentioned in my comment above, LVPWELL is totally ignored in everything if there is no DNWELL. No need to modify the pcell.

The issue that @spnadig is having is a separate issue. I need to look into it.

[proppy]

My understanding is that in #104 (comment) @RTimothyEdwards stated that LVPWELL without DNWELL was a valid usecase.

Shouldn't we make sure that this is also supported by the pcell?

[atorkmabrains]

@proppy yes, you could draw LVPWELL but the correct action is to not to draw it by default as it's disregarded in case the DNWELL is not drawn. The pcell is designed to allow the real use case of the LVPWELL. I don't advise to add LVPWELL if you are not really using it.

An exception to my comment above is the standard cells, standard cells should have LVPWELL just in case the user might want to use DNWELL later around the digital block later for any electrical reasons. But this use scenario is only valid for standard cells.

As for @RTimothyEdwards comments, what he basically wanted to say if I understand it correctly, is that LVPWELL is disregarded and we shall consider it as if it's not even drawn if it doesn't reside inside DNWELL and consider LVPWELL as part of the regular silicon substrate.

@RTimothyEdwards Please correct me if you think my comment above doesn't match yours.

[atorkmabrains]

@proppy I'm more concerned about the issue highlighted by @spnadig regarding the LVS. I need to understand that use case and why it didn't pass without DNWELL even if the LVPWELL is present. This has nothing to do with the pcell adding LVPWELL rather it's related to the LVS rule deck.

@spnadig Please share a test case and open an issue saying LVS doesn't pass due to LVPWELL. That might be a problem that we might need to fix.

[proppy]

@atorkmabrains I think this is due to the substrate connection of the bulk tie creating an additional signal (gf180mcu_gnd) when the LVPWELL is not present.

Is there a usecase for setting Bulk tie without drawing LVPWELL?

[atorkmabrains]

@proppy bulk tie doesn't need LVPWELL to happen, please read here:
https://en.wikipedia.org/wiki/CMOS

And BTW, that's the normal in almost all CMOS processes.

GF180MCU is a triple well technology, hence we need a PWELL marker:
https://www.researchgate.net/figure/Triple-well-NMOS-transistor-structure-See-the-colors-in-the-online-version_fig2_303530652

[proppy]

bulk tie doesn't need LVPWELL to happen, please read here: https://en.wikipedia.org/wiki/CMOS

Thanks for providing the links, I could find any mention of bulk tie nor its relation (if any) to PWELL on it, do you have an alternative source of documentation?

GF180MCU is a triple well technology, hence we need a PWELL marker:
https://www.researchgate.net/figure/Triple-well-NMOS-transistor-structure-See-the-colors-in-the-online-version_fig2_303530652

Without a PWELL it seems that the current LVS extraction is not able to infer the substrate connection of the BULK tied to SRC terminal for nmos device effectively leaving it floating with a different ground net, is that intentional? Or is there a different way to provide a hint for this implicit connection in the layout?

[atorkmabrains]

Without a PWELL it seems that the current LVS extraction is not able to infer the substrate connection of the BULK tied to SRC terminal for nmos device effectively leaving it floating with a different ground net, is that intentional? Or is there a different way to provide a hint for this implicit connection in the layout?

If what you mentioned is true that LVS requires LVPWELL to get the connectivity to substrate, then that's definitely a bug in LVS. I need the test case that has that issue. Also, are they using Google repo? If yes, then please tell them to use efabless one as Google repo is not updated and not cleaned.