I am really struggling for finalizing my design fo...
# lvs
b
I am really struggling for finalizing my design for mpw7 due to LVS errors on user_prokect_wrapper flow I had synthesis warnings and solved them, now synthesis.chk.rpt gives no warning I had 1 net mismatch. Subcircuit summary: Circuit 1: user_project_wrapper |Circuit 2: user_project_wrapper -------------------------------------------|------------------------------------------- axi_node_intf_wrap (1) |axi_node_intf_wrap (1) mba_core_region (1) |mba_core_region (1) sky130_sram_2kbyte_1rw1r_32x512_8 (2) |sky130_sram_2kbyte_1rw1r_32x512_8 (2) clk_rst_gen (1) |clk_rst_gen (1) peripherals (1) |peripherals (1) Number of devices: 6 |Number of devices: 6 Number of nets: 3791 Mismatch |Number of nets: 3790 Mismatch --------------------------------------------------------------------------------------- NET mismatches: Class fragments follow (with fanout counts): Circuit 1: user_project_wrapper |Circuit 2: user_project_wrapper --------------------------------------------------------------------------------------- Net: vccd1 |Net: vccd1 axi_node_intf_wrap/vccd1 = 1 | axi_node_intf_wrap/vccd1 = 1 mba_core_region/vccd1 = 1 | mba_core_region/vccd1 = 1 sky130_sram_2kbyte_1rw1r_32x512_8/vccd1 | sky130_sram_2kbyte_1rw1r_32x512_8/vccd1 peripherals/vccd1 = 1 | peripherals/vccd1 = 1 | clk_rst_gen/vccd1 = 1 | Net: clk_rst_gen_i/vccd1 |(no matching net) clk_rst_gen/vccd1 = 1 | --------------------------------------------------------------------------------------- Netlists do not match. Netlists do not match. what I undestand is there is a vccd1 connection for clk_rst_gen and another extra for clk_rst_gen_i. The module name is clk_rst_gen and the instantiation instance name is clk_rst_gen_i. This is not the case for other macro instantiations. I used same configurations for hardening macros for all modules. So is there a problem on clk_rst_gen module ? Is my assumption correct about vccd1 connections? This is the repo and I am adding related files here also: https://github.com/mbaykenar/mpw7_yonga_soc
d
Mostly Top-level vccd1 Power Hook-up to clk_rst_gen_i is missing. Check your the top-level PDN network, Mostly you many need adjust this macro placement to connect atleast one set vcc/ground power stripe.
b
is this due to small macro area (250 150)? it gives warning about "[WARNING]: Current core area is too small for a power grid. The power grid will be minimized."
when hardening clk_rsg_gen
m
There are 2
vccd1
nets in the layout.
vccd1
is connected to the
vccd1
port of
axi_node_intf_wrap
mba_core_region
sky130_sram_2kbyte_1rw1r_32x512_8
and
peripherals
.
vccd1
port of
clk_rst_gen
is not connected to anything at the upper hierarchy and is netlisted as
clk_rst_gen_i/vccd1
. Maybe because the core area is too small.
b
My opinion is taking the problematic small module inside another big module and rehardening the big module could be simple and fast solution ?
๐Ÿ‘ 1
m
or just reharden the small module to be larger. I recommend at least 250 tall. The key thing is the height. But you can also be careful about exactly where it's placed to make sure it picks up power and ground
๐Ÿ‘ 1
b
I solved it by removing small macro and putting the module inside another module and reharden it Now flow stucked at Magic DRC stage: Running Magic DRC Converting Magic DRC Violations to Magic Readable Format Converting Magic DRC Violations to Klayout XML Database then openroad process ate >62 GB of memory in a 64 GB machine and flow just freezed. By the way DRC errors are related to openram, which from the slack conversations I understand that can be ignored I couldn't find a DRC channel in slack, is openlane or openroad channel good to talk about it? or magic?
d
If you are using SRAM in your project, then you need to bypass Magic DRC in user_project_wrapper run. This is known issue. In Pre-check SRAM Magic DRC is bypassed
@Matt Venn You can add this SRAM Magic DRC issue as part of Known issue collection document.
b
thanks @Dinesh A did you modify makefile script to bypass magic DRC run? or any config parameters?
d
You can use makefile to bypass it, But it will bypass drc run during sub-macro run also. I am using interactive.tcl to over-ride bypass the DRC: https://github.com/dineshannayya/riscduino/blob/master/openlane/user_project_wrapper/interactive.tcl
b
thanks a lot !
I hope run_klayout_drc won't generate same issue !
I simply commented-out run_magic_drc in flow.tcl for now, if it succeed then I will work on interactive.tcl
d
This SRAM DRC issue specific to Magic tool, No issue observed with klayout tool
๐Ÿ‘ 2
m
that's what I do to