https://open-source-silicon.dev
Join Slack
Hey everyone. I am having some issues with LVS in precheck phase. we have a macro in our design in w...
# lvs
a
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_check.loglvs_config.json
m
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.
a
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?
m
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.
a
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?
m
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.
m
@Matthew Guthaus 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. @Asma Mohsin 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.
a
lvs.report
@Matthew Guthaus sorry i didn't get what u meant by they control the flow and whether its a hard macro or not. @Mitch Bailey so the lvs check within the flow is different from the precheck one?
m
@Asma Mohsin 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.
@Asma Mohsin 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?
Copy code
{
  "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)
sky130_sram_1kbyte_1rw1r_32x256_8.470.spice
a
@Mitch Bailey it passed LVS. Thankyou soo much
👍 1
11 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by