Sky130 tech LEF: Add (dummy) CUT layer after wells? about open_pdks HOT 6 CLOSED

I think it needs both the poly masterslice definition as well as the licon cut definition to make the commercial tools happy. Apparently they also need the overlap definition?

I'm happy to make the change to the efabless fork of the PDK repositories, but a pull request needs to be made for the technology LEF files of all of the standard cell libraries.

from open_pdks.

I think it needs both the poly masterslice definition as well as the licon cut definition to make the commercial tools happy. Apparently they also need the overlap definition?

I'm currently running Cadence successfully with just the "dummy cut" layer, but I don't know how it is with other vendors and I agree it would probably be best to fix it properly.

I'm happy to make the change to the efabless fork of the PDK repositories, but a pull request needs to be made for the technology LEF files of all of the standard cell libraries.

Thank you! I'll do a few more tests and then I'll start making those PRs.

from open_pdks.

So the LEF/DEF reference says :

Defines masterslice (nonrouting) or overlap layers in the design. Masterslice layers are
typically polysilicon layers and are only needed if the cell MACROs have pins on the polysilicon
layer.

Since our cells have no pins on poly, I don't think we need it. But we do need licon. Now the question is, do we need to specify any rules (ENCLOSURE, SPACING, ...) for licon? It seems like the PnR tool wouldn't need to know about any potential rules related to licon because it would never have to generate vias there, or am I missing something?

from open_pdks.

@ubfx: No, you've got it about right. The issue here is that the tools have absolutely no reason to be messing with the licon layer. The open source tools like OpenROAD and magic all understand that everything works perfectly well without it. I do not know why the commercial tools (and, maybe, the spec?) insist upon it being defined. There are other cases related to the LEF/DEF specs where (1) the spec was ambiguously worded; (2) some commercial tool interpreted the spec in the dumbest possible way; and (3) that interpretation became the de facto interpretation. I feel like this is another such example.

from open_pdks.

I see what you mean. Indeed, I wasn't able to find where the LEF/DEF specification requires the cut layer. It just says that you have to define the layers from the bottom up (not that you can't skip a layer).

At least Innovus seems to be happy with this configuration:

[...]
  TYPE MASTERSLICE ;
  PROPERTY LEF58_TYPE "TYPE PWELL ;" ;
END pwell

LAYER licon
  TYPE CUT ;
END licon

LAYER li1
  TYPE ROUTING ;
  DIRECTION VERTICAL ;
[...]

which would be the "minimally invasive" way to fix this.

from open_pdks.

Thank you for merging all of these!

from open_pdks.