SRAM macros failing LVS

[urish]

Environment

IHP-Open-PDK commit 860268e

Expected Behavior

SRAM macros pass LVS checks

Actual Behavior

SRAM macros fail LVS checks. I tested with the following macros:

• RM_IHPSG13_1P_1024x8_c2_bm_bist.gds
• RM_IHPSG13_1P_1024x64_c2_bm_bist.gds
• RM_IHPSG13_1P_64x64_c2_bm_bist.gds
• RM_IHPSG13_1P_4096x8_c3_bm_bist.gds

The errors seem to be related to RSC_IHPSG13_CDLYX1_DUMMY - I'm attaching a copy of the LVS run dir with the extracted circuit and the .lvsdb file:

lvs_run_2024_10_28_12_29_51.zip

Steps to Reproduce the Problem

Check out this repo (dev branch), set PDK_ROOT to point at the checked out repo, and then run:

cd $PDK_ROOT/ihp-sg13g2/libs.tech/klayout/tech/lvs

python run_lvs.py --layout $PDK_ROOT/ihp-sg13g2/libs.ref/sg13g2_sram/gds/RM_IHPSG13_1P_1024x8_c2_bm_bist.gds --netlist $PDK_ROOT/ihp-sg13g2/libs.ref/sg13g2_sram/cdl/RM_IHPSG13_1P_1024x8_c2_bm_bist.cdl

[sergeiandreyev]

Hi @urish, for the SRAM cells the user should set additional parameters for the LVS run, with default settings it will not work
we have to figure out if it's possible with the current implementation of the KLayout LVS
@atorkmabrains, @FaragElsayed2, can we discuss this?

[urish]

Thanks! Is there a way to tell LVS to skip the SRAM cells?

[sergeiandreyev]

Thanks! Is there a way to tell LVS to skip the SRAM cells?

I'll check with Mabrains team..
I double checked the SRAM LVS using our commercial tools and the status is:
the following have LVS mismatches (UNMATCHED SCHEMATIC PIN LABELS): 1024x8, 1024x16, 4096x8, 4096x16
all others are clean

we will review the issues if these are critical or could be waived

[atorkmabrains]

blank_circuit command should be able to do that for you. It has to be included in the rule deck.

[urish]

Thanks, unfortunately, blank_circuit seems to confuse KLayout - when enabling it for RM_IHPSG13_1P_1024x8_c2_bm_bist, suddenly, there are many mismatched nets / devices at the top level (before they were matched correctly).

schematic.blank_circuit('RM_IHPSG13_1P_1024X8_C2_BM_BIST')
netlist.blank_circuit('RM_IHPSG13_1P_1024x8_c2_bm_bist')

Here's variation, which only tries to blacklist the mismatching cells inside the SRAM macro:

blank_circuit("RSC_IHPSG13_CDLYX1_DUMMY")
blank_circuit("RSC_IHPSG13_CINVX2")
blank_circuit("RSC_IHPSG13_CINVX8")
blank_circuit("RSC_IHPSG13_FILLCAP4")
blank_circuit("RSC_IHPSG13_FILLCAP8")

It is almost working - for reason, we're still getting mismatches for the pins of RSC_IHPSG13_FILLCAP4 and RSC_IHPSG13_FILLCAP8:

I'm attaching the GDS, CDL and the LVS script for this variation. I'm running it as follows:

klayout -b -rd in_gds=6_final.gds -rd cdl_file=6_final_concat.cdl -rd report_file=6_lvs.lvsdb -rd run_mode=deep -r sg13g2_full.lylvs

issue-239.zip

[sergeiandreyev]

Thanks! Is there a way to tell LVS to skip the SRAM cells?

I'll check with Mabrains team.. I double checked the SRAM LVS using our commercial tools and the status is: the following have LVS mismatches (UNMATCHED SCHEMATIC PIN LABELS): 1024x8, 1024x16, 4096x8, 4096x16 all others are clean

we will review the issues if these are critical or could be waived

now the SRAM cells are fully LVS clean when using commercial tools
please note that this is not related to KLayout LVS issues, this has to be dealt separately

[atorkmabrains]

@sergeiandreyev Anything is required from us?

[sergeiandreyev]

Hi @atorkmabrains, yes, I will send an email

[KrzysztofHerman]

@atorkmabrains a gentle reminder on this action

[FaragElsayed2]

@sergeiandreyev @KrzysztofHerman

I have investigated for RM_IHPSG13_1P_64x64_c2_bm_bist.gds using deep run mode and here my findings:

1. For RSC_IHPSG13_CDLYX1_DUMMY cell, it uses lvsres resistor but it doesn't match the name implemented in LVS.
   

2. For RSC_IHPSG13_WLDRVX8, it has a similar issue related to not extracting the devices in their cells (Hierarchy issue), I belive this will be fixed in flat mode run. Refer to LVS unexpectedly failing #254 &

3. There are some cells doesn't exist in layout but exist in cdl, I belvie they be exist in layout at the top level so this may be fixed in flat run.
   

CC @atorkmabrains

[atorkmabrains]

@KrzysztofHerman @sergeiandreyev We could discuss further in a meeting.