Mitch Bailey

04/06/2023, 1:49 AM
@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
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
option, are pins still created? Maybe the solution is as simple as removing the
option in openlane.

Tim Edwards

04/06/2023, 2:02 AM
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.
@Mitch Bailey: It might be caused by the power grid generator creating a LEF view of the power grid with every power stripe marked as a port so that the P&R tools know where to connect to it, followed by reading that LEF view into the layout. I'm definitely fuzzy on the details, though, and I don't know where to find it in the openlane scripts.

Mitch Bailey

04/06/2023, 3:27 AM
@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
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
Moving discussion to efabless slack.