In the sky130_fd_sc_hd cell library, for all the

.magic.lef

files, while the NWELL extends the entire width of the cell, the PWELL is mostly just one small rectangular shape underneath the GND rail. This (and maybe along with other issues) caused PWELL to be open in Innovus.

PIN VNB
    DIRECTION INOUT ;
    USE GROUND ;
    PORT
      LAYER pwell ;
        RECT 0.145000 -0.085000 0.315000 0.085000 ;
    END
  END VNB
  PIN VPB
    DIRECTION INOUT ;
    USE POWER ;
    PORT
      LAYER nwell ;
        RECT -0.190000 1.305000 3.410000 2.910000 ;
    END
  END VPB

We are using

sky130_fd_sc_hd__tapvpwrvgnd_1

well tap. I see these

.magic.lef

files are part of the repo, but are they provided by the PDK or generated from magic? Is this a known issue?

idk where this files are from. But looks like the pwell déclaration in lef is wrong. In the gds it should be okay. Keep in mind that everything that is not nwell is a pwell.

Yes, for the standard cells, PWELL should be considered to be open; it is a port that is separate from the ground connection (as is nwell). The magic.lef files were generated from magic so that there would be consistency among all of the standard cell libraries, because the original standard cell libraries from SkyWater were utterly inconsistent, as well as being just wrong in many cases.

I see. But at least for nwell we don’t see open violations in Innovus. I assume that’s because in LEF nwell occupies the entire width of the cell, so they abut through the row and form connection with tap cell, which has a VPWR port on both nwell and met1 layer. But that’s not the case for pwell because the shape given in LEF for VNB is not abutment (in fact, they don’t even seem to be in GDS, but I guess there’s viali (mcon) in gds so the connection is still established.) I understand we can safely ignore the violation in Innovus if the magic DRC check is clean. But is this how everyone proceeds?

It's not an issue for Openlane. There is no "pwell" in GDS, as you noted, although there is a substrate pin layer (122:16). Lack of an nwell is implicitly the same as a pwell, and is equivalent to the substrate. But LEF does not define "substrate", only "nwell" and "pwell". I guess the LEF could be redefined with the pwell layer spanning the whole cell width, or rather anything inside the cell boundary that does not have nwell. The existing method reads in the GDS, which converts the label layer to type "pwell" and writes that back out to the LEF file, so the LEF file only defines "pwell" where the VNB label is in the GDS. I don't know if it would work simply to define "SHAPE ABUTMENT" for the pwell layer. Would that work, even though the pwell layer geometry doesn't span the width of the cell?

Thanks for the explanation! It makes a lot sense now. I doubt simply specifying the shape as abutment will work. Once I get time I can experiment and let you know. Another way to resolve this is to hide VPB and VNB from LEF when exporting. It’s not ideal since it requires some extra steps when performing LVS, since spice model has those pins. But it will eliminate the violation messages.

@User: The original SkyWater LEF attached VPB and VNB to local interconnect, which is just wrong and caused our tools to short them to the power rails. So I used the pwell / nwell masterslice layers from LEF version 5.7+, but I didn't have any examples of that usage, so I had to figure it out from a combination of reading the LEF spec and getting feedback from users saying the tools didn't like the syntax I used.

Hi, Tim, Just to check that will this be fixed or changed in the near future? We are trying to make the DRC debugging loop shorter, so, we want to get rid of any false report if possible. Let me know if you plan to fix this minor bug. Thanks!

As far as I'm concerned, all our open source tools work correctly with the LEF files as we have them. Innovus seems to be lacking a proper understanding of what a substrate is, and needs to be fixed.

Got it, thanks for the reply!