open-source-silicon.dev

LVS_check.log

lvs_config.json

Hey everyone. I am having some issues with LVS in precheck phase. we have a macro in our design in which SRAM macro from skywater is used. hence its a submacro in the top wrapper.  LVS passed inside the flow but in prechecks it failed cause of some mismatches with this sram macro.

LVS should be using an abstracted version of the SRAM macro. The SRAM macros all pass LVS but it is very sensitive to which version of magic does the extraction and which version of netgen does the LVS.

I am not sure if version could be an issue as lvs passed within the flow but its failing in prechecks. shouldn't it fail in the flow too if its version issue?

In the flow likely abstracts the SRAM macro. It doesn't have internals. Or at least it used to be that way.

It just checks that the pins to the SRAM are connected properly.

Yes and that's the only thing we can do at our end right. Make pin connections right. As it's a macro from sky water. Or am I getting something wrong?

That is correct. (It's actually a macro from my group...)

But they control the flow and whether it is a hard macro or not.

<@U0175T39732> Actually, the `lvs_config.json` file that they’re using should enable device level LVS on the SRAM macro. However, you are correct in that it is sensitive to the magic/netgen and pdk versions.

<@U03TGE5CB34> Thanks for including the `lvs_config.json` file and the `LVS_check.log`. Can you also share this file `/home/asma/open_eFPGA_dirk/precheck_results/25_DEC_2024___23_20_59/outputs/reports/lvs.report`?

You should be able to see a net mismatch at the top level.

<@U0175T39732> sorry i didn't get what u meant by they control the flow and whether its a hard macro or not. <@U017X0NM2E7> so the lvs check within the flow is different from the precheck one?

<@U03TGE5CB34> Yes, the openlane flow LVS is an abstract LVS because there is no way to specify the source netlists for macros (or standard cells). The precheck LVS uses the `lvs_config.json` file to specify the source files and other options required for device level LVS.

sky130_sram_1kbyte_1rw1r_32x256_8.470.spice

<@U03TGE5CB34> My guess is that the sram source does not correspond to the pdk used to extract the layout `1.0.470-0-g6d4d117`.
Save the attached file to `lvs/spice/sky130_sram_1kbyte_1rw1r_32x256_8.470.spice` and then use the following `lvs_config.json` file?
```{
    "STD_CELL_LIBRARY": "sky130_fd_sc_hd",	
    "INCLUDE_CONFIGS": [
        "$LVS_ROOT/tech/$PDK/lvs_config.base.json"
    ],
	"TOP_SOURCE": "user_project_wrapper",
	"TOP_LAYOUT": "$TOP_SOURCE",
	"EXTRACT_FLATGLOB": [
        "*_nmos_m*",
        "*_pmos_m*"
    ],
	"EXTRACT_ABSTRACT": [
		"*__fill_*",
		"*__fakediode_*",
		"*__tapvpwrvgnd_*"
	],
	"LVS_FLATTEN": [
		""
	],
	"LVS_NOFLATTEN": [
		""
	],
	"LVS_IGNORE": [
		""
	],
	"LVS_SPICE_FILES": [
		"$PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd/spice/sky130_ef_sc_hd__decap_12.spice",
		"$UPRJ_ROOT/lvs/spice/sky130_sram_1kbyte_1rw1r_32x256_8.470.spice",
		"$PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice"
	],
	"LVS_VERILOG_FILES": [
		"$UPRJ_ROOT/verilog/gl/*.v",
		"$UPRJ_ROOT/verilog/gl/$TOP_SOURCE.v"
	],
	"LAYOUT_FILE": "$UPRJ_ROOT/gds/$TOP_LAYOUT.gds"
}```
(edited)

<@U017X0NM2E7> it passed LVS. Thankyou soo much