@Tim Edwards We were talking about long LVS times being caused by the number of labels on the openlane designs. Looks like the labels are created with the

-labels

option of

def read

.

The "-labels" option to the "def read" command causes each net in the NETS and SPECIALNETS sections of the DEF file to be annotated with a label having the net name as the label text.

Even without the

-labels

option, are pins still created? Maybe the solution is as simple as removing the

-labels

option in openlane.

def read -labels

would create a point label which is not a port; it looks for the center of the first wire in a net and drops the label there. That's for internal nets that are not part of the PINS section in the DEF file. The port labels spanning the length and height of each power rail might come from doing something like annotating the layout from a LEF file. Also, labels created with

def read -labels

are not sticky (since by definition they're sitting directly on top of the layer they're connected to), so they won't affect the extraction time.

@Tim Edwards I modified the gds for slot-001 of mpw-8 manually by removing all the labels on label layers (39,010 texts) at the

user_proj_example

equivalent level but keeping the labels on the pin layers. The extraction runtime went from 6:43:07 to 8:00. This design had only standard cell placements with no SRAM. Using

do no labelcheck

@Marwan Abbas @donn