Hi folks, I understand, that in this channel users can propose their project to be reviewed by others, right ? I would love to have some killing issues cleaned before deadline. Anyone interested in reviewing my project (only GDS submitted so far), which passes tapeout check on the efabless site. https://github.com/cloudxcc/WaveSync_7.git For instance, is the power connection of the macros I used (SRAM and custom) okay ? I would be happy to treat reviewers for lunch if we meet at any of the OrConf etc. conferences !!! In any case, as always, thank you in advance. Cheers, Tobias

I don't see any power connections to cawb. Also, do you see power connections to the SRAMs?

Thank you Mitch! I updated the file: verilog/gl/user_proj_example.v The CAWB instantiation has the power connectors: cawb cai (.VGND(vssd1), .VPWR(vccd1), ... whereas the SRAM instantiations don't. What I do in my flow: Step 1: I do the stand-alone CAWB macro run here: https://github.com/cloudxcc/WaveSync_7_cawb.git setting “"DESIGN_IS_CORE": 0,” in config.json. Step 2: I copy over gds and lef of CAWB to the WaveSync project. Step 3: I copy over gds and lef of SRAMs from the OpenRam dev branch. Step 4: In the WaveSync project, I use the Verilog files of the SRAMs from the OpenRAM dev branch as a black box. Step 5: In the WaveSync project, I use the original, top-level RTL file of the CAWB project as a black box. (What is missing in this top-level Verilog file is the “`ifdef USE_POWER_PINS vccd1, vssd1, `endif” entry, compared to the SRAM Verilog files.) Any solution to the problem is highly welcome. Thanks again, Tobias

Check your config file for power routing

set ::env(FP_PDN_MACRO_HOOKS) "\
	cai vccd1 vssd1 vccd1 vssd1,
    sram1 vccd1 vssd1 vccd1 vssd1,
    etc."

I think the order is parent-vcc parent-vss macro-vcc macro-vss. Separate each macro line with a comma.

Mitch, thank you for your support. As advised, I used the FP_PDN_MACRO_HOOKS variable, rerun the project and uploaded it again. I still don’t see the power connections. Do you think you might find the time to have a look at it again. https://github.com/cloudxcc/WaveSync_7_cawb.git Thanks a lot in advance, Tobias

Sure, but the last commit to that repo was 8 days ago. Is it up-to-date?

Sorry, that was the link to the macro, the project itself is: https://github.com/cloudxcc/WaveSync_7.git

Try adding something like this to your

user_proj_example/config.tcl

to connect power to the macros.

set ::env(FP_PDN_MACRO_HOOKS) "\
        cai vccd1 vssd1 vccd1 vssd1, \
        cubev_dhi vccd1 vssd1 vccd1 vssd1, \
        cubev_dli vccd1 vssd1 vccd1 vssd1, \
        cubev_phi vccd1 vssd1 vccd1 vssd1, \
        cubev_pli vccd1 vssd1 vccd1 vssd1, \
        cubev_reg_0 vccd1 vssd1 vccd1 vssd1, \
        cubev_reg_1 vccd1 vssd1 vccd1 vssd1, \
        cubev_reg_2 vccd1 vssd1 vccd1 vssd1, \
        cubev_reg_3 vccd1 vssd1 vccd1 vssd1, \
        cubev_reg_4 vccd1 vssd1 vccd1 vssd1, \
        cubev_reg_5 vccd1 vssd1 vccd1 vssd1, \
        cubev_rf1i vccd1 vssd1 vccd1 vssd1, \
        cubev_rf2i vccd1 vssd1 vccd1 vssd1, \
        cubev_cai vccd1 vssd1 vccd1 vssd1"

That's exactly what I did.

I do not see that in the repo.

openlane/user_proj_example/config.tcl

# SPDX-FileCopyrightText: 2020 Efabless Corporation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      <http://www.apache.org/licenses/LICENSE-2.0>
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# SPDX-License-Identifier: Apache-2.0

set ::env(PDK) $::env(PDK)
set ::env(STD_CELL_LIBRARY) "sky130_fd_sc_hd"

set script_dir [file dirname [file normalize [info script]]]

set ::env(DESIGN_NAME) user_proj_example

set ::env(VERILOG_FILES) "\
	$::env(CARAVEL_ROOT)/verilog/rtl/defines.v \
	$script_dir/../../verilog/rtl/user_proj_example.v \
	$script_dir/../../verilog/rtl/cubev_rv32imc_p3.v  \
        $script_dir/../../verilog/rtl/gpio.v  \
	$script_dir/../../verilog/rtl/minisoc.v\
	$script_dir/../../verilog/rtl/clock_gen_empty.v"

#	$script_dir/../../verilog/rtl/ca.v  \

set ::env(DESIGN_IS_CORE) 0
set ::env(CELL_PAD) 2 

set ::env(CLOCK_PORT) "io_in\[32\]"
set ::env(CLOCK_NET) "clk_root"
set ::env(CLOCK_PERIOD) "50"
set ::env(RESET_PORT) "wb_rst_i"
set ::env(RESET_NET) "\i_cg.resetn"

set ::env(FP_SIZING) absolute
#set ::env(DIE_AREA) "0 0 2600 2550"
set ::env(DIE_AREA) "0 0 2600 3100"

set ::env(FP_PIN_ORDER_CFG) $script_dir/pin_order.cfg

## Internal Macros
### Macro Placement
set ::env(MACRO_PLACEMENT_CFG) $script_dir/macro.cfg

### Black-box verilog and views
set ::env(VERILOG_FILES_BLACKBOX) "\
	$script_dir/../../verilog/rtl/cawb.v\
	$script_dir/../../verilog/rtl/mem/sky130_sram_1kbyte_1rw1r_32x256_8.v"

#	$script_dir/../../verilog/rtl/minisoc.v\

set ::env(EXTRA_LEFS) "\
	$script_dir/../../lef/cawb.lef \
	$script_dir/../../lef/sky130_sram_1kbyte_1rw1r_32x256_8.lef"

#	$script_dir/../../lef/minisoc.lef \

set ::env(EXTRA_GDS_FILES) "\
	$script_dir/../../gds/cawb.gds \
	$script_dir/../../gds/sky130_sram_1kbyte_1rw1r_32x256_8.gds"

#	$script_dir/../../gds/minisoc.gds \

set ::env(PL_BASIC_PLACEMENT) 0
set ::env(PL_TARGET_DENSITY) 0.18

# Maximum layer used for routing is metal 4.
# This is because this macro will be inserted in a top level (user_project_wrapper) 
# where the PDN is planned on metal 5. So, to avoid having shorts between routes
# in this macro and the top level metal 5 stripes, we have to restrict routes to metal4.  
# 
set ::env(RT_MAX_LAYER) {met4}

# You can draw more power domains if you need to 
set ::env(VDD_NETS) [list {vccd1}]
set ::env(GND_NETS) [list {vssd1}]

set ::env(DIODE_INSERTION_STRATEGY) 4 
# If you're going to use multiple power domains, then disable cvc run.
set ::env(RUN_CVC) 1

That’s an older version (6 days ago). I had trouble with tapeout check on Efabless site yesterday, so I temporarily uploaded an older version to check if it works on a version which already passed. The older config.tcl file must have sneaked out by using “git push --force”. Sorry for that. I double checked again, and it is definitely in my local copy. I will release the full project in a couple of hours as a preparation for the OpenLane issue (or is it an OpenRoad issue ?). I still have to make RTL look nicer, it still doesn't look releaseable.

The

FP_PDN_MACRO_HOOKS

that I suggested was a template the actual pin / power names need to match your actual data. For example, from your

verilog/gl

cawb cai (.VGND(vssd1),
    .VPWR(vccd1),

it looks like the

cawb

pins are

VGND

and

VPWR

not

vccd1

and

vssd1

like what you've defined here

set ::env(FP_PDN_MACRO_HOOKS) "\
        cai vccd1 vssd1 vccd1 vssd1, \

From

openlane/configuration/README.md

FP_PDN_MACRO_HOOKS	
Specifies explicit power connections of internal macros to the top level power grid. Comma separated list of macro instance names, power domain vdd and ground net names, and macro vdd and ground pin names: <instance_name> <vdd_net> <gnd_net> <vdd_pin> <gnd_pin>

Is there something in your run logs about not being able to find power pins? Maybe grep

Power planning the following nets

and look around there.

@Mitch Bailey Thank you for your patience and your support. I guess the problem was that I placed the srams on example level (which I considered as top-level) and not on wrapper level. Now LVS passes. Thanks again !