klayout LVS isn't set up for sky130, is it?

@Matthew Guthaus It is: https://github.com/efabless/sky130_klayout_pdk/tree/main/sky130_tech/tech/sky130/lvs

Filing a bug that docopt isn't installed in openlane so it cannot be run.

You need to install docopt at your end.

I'm trying to use the openlane docker image (for my class)

(and not have them rebuild the entire docker image)

Ah, I see

Is there a requirement for klayout version? I'm using 0.28.2 (from OpenLane) and it gives some errors:

ERROR: Reading /openlane/sky130_klayout_pdk/sky130_tech/tech/sky130/lvs/sky130.lylvs: XML parser error: error occurred while parsing element in line 31, column 49
ERROR: Reading /openlane/sky130_klayout_pdk/sky130_tech/tech/sky130/lvs/sky130.lylvs: XML parser error: error occurred while parsing element in line 31, column 49

I'm not sure why you are getting this.

Hm, the sky130_layout_pdk directory structure seems odd compared to other klayout technologies

sky130_layout_pdk is just the source. I believe that Volare version of the PDK pulls the data from it.

Ah, so that is what is in openlane/pdks then

It's installed from volare

It's 8 PM here and I'm tired, I'll take a look tomorrow

Volare is the build platform for PDKs.

yeah

@donn Please correct me if I'm wrong.

This is why there is /openlane/pdks/volare/sky130/*

sky130/tech/klayout/drc

That is what I've been using

If not, then I believe @Tim Edwards needs to add that to the build process.

I just pull klayout files from the repository at efabless, which is the one that you (Amro) said that we should be using (in preference to the one under mabrains):

KLAYOUT_URL = <https://github.com/efabless/sky130_klayout_pdk>

Ah, there's some bugs in the sky130.lylvs file. There is a URL included, but it messes with the XML:

30 # You should have received a copy of the GNU Affero General Public License
 31 # along with this program.  If not, see <<https://www.gnu.org/licenses/>>.

Thanks @Tim Edwards for confirming.

May I ask you how you are running the LVS?

I'm not yet. I'm just running klayout.

This file is used for allowing to run LVS from inside klayout and it's not properly tested.

There's also some errors referring to gdsfactory. Is that also a dependency?

ERROR: /openlane/pdks/sky130A/libs.tech/klayout/pymacros/cells/via_generator.py:23: No module named 'gdsfactory'
  /openlane/pdks/sky130A/libs.tech/klayout/pymacros/cells/via_generator.py:23
  /openlane/pdks/sky130A/libs.tech/klayout/pymacros/cells/vias.py:21
  /openlane/pdks/sky130A/libs.tech/klayout/pymacros/cells/__init__.py:22
  /openlane/pdks/sky130A/libs.tech/klayout/pymacros/sky130.lym:9 (class ModuleNotFoundError)

@Matthew Guthaus before you spend too much time on klayout lvs, you might want to confirm that it can handle hierarchies with cells that do not match exactly. magic will virtually flatten mismatched cells and compare at the parent hierarchy. @Amro Tork Do you have any test results in klayout with cells that don’t match at the cell level, but will match at a higher hierarchy when virtually flattened? From the klayout web site

Hierarchical analysis: KLayout got a hierarchical layout processing engine to support hierarchical LVS. Hierarchical processing means that boolean operations happen inside the local cell environment as far as possible. As a consequence, devices are recognized inside their layout cell and layout cells are turned into respective subcircuits in the netlist. The netlist compare will benefit as it is able follow the circuit hierarchy. This is more efficient and gives better debugging information in case of mismatches. As a positive side effect of hierarchical layout processing the runtimes for some boolean and other operations is significantly reduced in most cases.
Hierarchically stable: KLayout won't modify the layout's hierarchy nor will it introduce variants - at least for boolean and some other operations. This way, matching between layout and schematic hierarchy is maintained even after hierarchical DRC operations. Variants are introduced only for some anisotropic operations, the grid snap method and some other features which require differentiation of cells in terms of location and orientation.

@Mitch Bailey I'm only using this for my class so that students can learn layout, DRC, and LVS at a cell level. Then use it to view layouts and debug errors.

@Mitch Bailey That specific test, we didn’t test. But we have seen both failures on flat and hierarchical levels for small and large designs. We actually demonstrated the use of KLayout usage on a fullchip LVS.

Ok. I assumed it was for openram.