Closed lrburle closed 5 months ago
d-m-bailey
commented
5 months ago @lrburle The default pdn settings expect your custom macros to have power rails on met4 with the corresponding obstructions in lef. There is a way to modify the pdn routines to connect to lower layers. Can you share your custom macro lef files?
lrburle
commented
5 months ago 
kareefardi
commented
5 months ago @lrburle The LEF file that you shared has two macros and none of the have power ports (or any ports at all).
lrburle
commented
5 months ago @d-m-bailey @kareefardi Apologies for attaching the incorrect lef file. I updated my previous message with the correct lef file. Thanks!
kareefardi
commented
5 months ago @lrburle Thank you. I can see that as @d-m-bailey was saying power pins are on met3. You need to provide a custom FP_PDN_CFG file. Take a look at this comment and see if it helps https://github.com/The-OpenROAD-Project/OpenLane/issues/2019#issuecomment-1767004201.
lrburle
commented
5 months ago @kareefardi Unfortunately, simply adding the pdn_cfg.tcl and adding the text shown in #2019 (comment) didn't seem to change anything in the final layout. Is there something else I'm missing? Should I consider adding met3 -> met4 vias across my power rails to attempt to remedy this?
I added in the "FP_PDN_CFG": "dir::pdn_cfg.tcl", line to my config.json file and used the following file as my modified pdn_cfg.tcl file:
# Copyright 2020-2022 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.
source $::env(SCRIPTS_DIR)/openroad/common/set_global_connections.tcl
set_global_connections
set secondary []
foreach vdd $::env(VDD_NETS) gnd $::env(GND_NETS) {
if { $vdd != $::env(VDD_NET)} {
lappend secondary $vdd
set db_net [[ord::get_db_block] findNet $vdd]
if {$db_net == "NULL"} {
set net [odb::dbNet_create [ord::get_db_block] $vdd]
$net setSpecial
$net setSigType "POWER"
}
}
if { $gnd != $::env(GND_NET)} {
lappend secondary $gnd
set db_net [[ord::get_db_block] findNet $gnd]
if {$db_net == "NULL"} {
set net [odb::dbNet_create [ord::get_db_block] $gnd]
$net setSpecial
$net setSigType "GROUND"
}
}
}
set_voltage_domain -name CORE -power $::env(VDD_NET) -ground $::env(GND_NET) \
-secondary_power $secondary
# Assesses whether the design is the core of the chip or not based on the
# value of $::env(DESIGN_IS_CORE) and uses the appropriate stdcell section
if { $::env(DESIGN_IS_CORE) == 1 } {
# Used if the design is the core of the chip
define_pdn_grid \
-name stdcell_grid \
-starts_with POWER \
-voltage_domain CORE \
-pins "$::env(FP_PDN_VERTICAL_LAYER) $::env(FP_PDN_HORIZONTAL_LAYER)"
add_pdn_stripe \
-grid stdcell_grid \
-layer $::env(FP_PDN_VERTICAL_LAYER) \
-width $::env(FP_PDN_VWIDTH) \
-pitch $::env(FP_PDN_VPITCH) \
-offset $::env(FP_PDN_VOFFSET) \
-spacing $::env(FP_PDN_VSPACING) \
-starts_with POWER -extend_to_core_ring
add_pdn_stripe \
-grid stdcell_grid \
-layer $::env(FP_PDN_HORIZONTAL_LAYER) \
-width $::env(FP_PDN_HWIDTH) \
-pitch $::env(FP_PDN_HPITCH) \
-offset $::env(FP_PDN_HOFFSET) \
-spacing $::env(FP_PDN_HSPACING) \
-starts_with POWER -extend_to_core_ring
add_pdn_connect \
-grid stdcell_grid \
-layers "$::env(FP_PDN_VERTICAL_LAYER) $::env(FP_PDN_HORIZONTAL_LAYER)"
} else {
# Used if the design is a macro in the core
define_pdn_grid \
-name stdcell_grid \
-starts_with POWER \
-voltage_domain CORE \
-pins $::env(FP_PDN_VERTICAL_LAYER)
add_pdn_stripe \
-grid stdcell_grid \
-layer $::env(FP_PDN_VERTICAL_LAYER) \
-width $::env(FP_PDN_VWIDTH) \
-pitch $::env(FP_PDN_VPITCH) \
-offset $::env(FP_PDN_VOFFSET) \
-starts_with POWER
}
# Adds the standard cell rails if enabled.
if { $::env(FP_PDN_ENABLE_RAILS) == 1 } {
add_pdn_stripe \
-grid stdcell_grid \
-layer $::env(FP_PDN_RAIL_LAYER) \
-width $::env(FP_PDN_RAIL_WIDTH) \
-followpins \
-starts_with POWER
add_pdn_connect \
-grid stdcell_grid \
-layers "$::env(FP_PDN_RAIL_LAYER) $::env(FP_PDN_VERTICAL_LAYER)"
}
# Adds the core ring if enabled.
if { $::env(FP_PDN_CORE_RING) == 1 } {
add_pdn_ring \
-grid stdcell_grid \
-layers "$::env(FP_PDN_VERTICAL_LAYER) $::env(FP_PDN_HORIZONTAL_LAYER)" \
-widths "$::env(FP_PDN_CORE_RING_VWIDTH) $::env(FP_PDN_CORE_RING_HWIDTH)" \
-spacings "$::env(FP_PDN_CORE_RING_VSPACING) $::env(FP_PDN_CORE_RING_HSPACING)" \
-core_offset "$::env(FP_PDN_CORE_RING_VOFFSET) $::env(FP_PDN_CORE_RING_HOFFSET)"
}
define_pdn_grid \
-macro \
-default \
-name macro \
-starts_with POWER \
-halo "$::env(FP_PDN_HORIZONTAL_HALO) $::env(FP_PDN_VERTICAL_HALO)"
add_pdn_connect \
-grid macro \
-layers "$::env(FP_PDN_VERTICAL_LAYER) $::env(FP_PDN_HORIZONTAL_LAYER)"
# Added in additional layer information for the macros
add_pdn_connect \
-grid macro \
-layers "met3 met4"@lrburle I don't think the power router will route to small power pins. Try extending the met3 power rails/pins from the left of the macro to the right (and remake the lef). The power router should able to run met4 power rails vertically and drop vias to the met3 rails.
lrburle
commented
5 months ago @d-m-bailey Thanks for the feedback! I'm now having an issue with my modified pins:
[STEP 13]
[INFO]: Running Detailed Routing (log: ../import/yukari1/lrburle/google_ring_oscillator/caravel/openlane/user_project_wrapper/runs/24_01_15_09_03/logs/routing/13-detailed.log)...
[ERROR]: during executing openroad script /openlane/scripts/openroad/droute.tcl
[ERROR]: Log: ../import/yukari1/lrburle/google_ring_oscillator/caravel/openlane/user_project_wrapper/runs/24_01_15_09_03/logs/routing/13-detailed.log
[ERROR]: Last 10 lines:
Units: 1000
Number of layers: 13
Number of macros: 458
Number of vias: 25
Number of viarulegen: 25
[INFO DRT-0150] Reading design.
[ERROR DRT-0416] Term vssd1 of ro1 contains offgrid pin shape. Pin shape ( 1535100 2460977 ) ( 1535395 2461003 ) is not a multiple of the manufacturing grid 5.
Error: droute.tcl, 38 DRT-0416
child process exited abnormally
[ERROR]: Creating issue reproducible...It seems that regardless of how I modify my met3 layer for the power pins, I receive the same pin shape error. I am conducting all of my power pin changes in magic:
I have been unsuccessful in tracking down where these coordinates are derived so I'm not sure how I should go about resolving the pin shape issues.
d-m-bailey
commented
5 months ago @lrburle To get the coordinates in microns, divide the database units by 200.
maliberty
commented
5 months ago The pin location is a combination of the pin shapes in the block and the coordinates at which you instantiate the block. Either could be off
@d-m-bailey should that be 2000 ?
d-m-bailey
commented
5 months ago Thanks @maliberty. I was thinking about the magic internal coordinates.
The error log @lrburle shared is probably not related to magic and is showing in nm. So the coordinates would probably be (1535.100 2460.977) in microns (scaled by 1000).
@lrburle does that match?
lrburle
commented
5 months ago @d-m-bailey Yes it does. Thanks for the clarification.
Unfortunately, with the changes to making the pins larger (as mentioned in the above comment), the router still doesn't seem to be connecting my pins to the power rails.
Same area in the magic layout view for a clearer picture of my adjusted power pins:
I'm currently still modifying the layouts to see if I can make a difference within the router.
kareefardi
commented
5 months ago @lrburle Can you share your source files? Perhaps I can take a look.
d-m-bailey
commented
5 months ago @lrburle Looks like your power rails may be met1. Is that correct?
Can you check your lef file to be sure that the entire metal1 area is defined as a power pin?
lrburle
commented
5 months ago @d-m-bailey Yes. The power rails are metal1. It seems that labeling the entire metal layers as vccd1 or vssd1 doesn't make a difference for the router:
magic layout version:
Something of note, if I label my bottom rail as vssd1 as well, the router throws the error mentioned before:
[ERROR]: during executing openroad script /openlane/scripts/openroad/droute.tcl
[ERROR]: Log: ../import/yukari1/lrburle/google_ring_oscillator/caravel/openlane/user_project_wrapper/runs/24_01_16_08_33/logs/routing/13-detailed.log
[ERROR]: Last 10 lines:
Units: 1000
Number of layers: 13
Number of macros: 458
Number of vias: 25
Number of viarulegen: 25
[INFO DRT-0150] Reading design.
[ERROR DRT-0416] Term vssd1 of ro1 contains offgrid pin shape. Pin shape ( 1551100 2460977 ) ( 1551395 2461003 ) is not a multiple of the manufacturing grid 5.
Error: droute.tcl, 38 DRT-0416
child process exited abnormally
[ERROR]: Creating issue reproducible...If I remove the bottom label and keep the top label as vssd1, caravel finishes the run. (vccd1 is the middle rail).
@kareefardi Sure. Here is my caravel repo: https://github.com/lrburle/caravel_google_ring_oscillators. Keep in mind I have 16 custom layouts so all suggestions mentioned above only apply to ro1 in the final GDS file at the moment.
kareefardi
commented
5 months ago @lrburle I am not sure what should I run. I tried user_project_wrapper and got the following:
[WARNING PDN-0232] macro - ro7 does not contain any shapes or vias.
[WARNING PDN-0232] macro - ro15 does not contain any shapes or vias.
[ERROR PDN-0233] Failed to generate full power grid.
PDN-0233Which is different from the errors you reported before.
lrburle
commented
5 months ago @kareefardi I use make user_project_wrapper to run my instance. I"m not sure why you are getting those warnings / error.
In a bash shell environment, I run:
export PDK=sky130A
make setup
make user_project_wrapperI cloned my repository for a clean build and was able to successfully complete the caravel run using those commands. Not sure if that helps. Otherwise, you may comment out all other layouts using the macro.cfg and the user_project_wrapper.v files since I'm focused on getting ro1 through. The other layouts will be modified once the power rail issue is resolved:
REPO_HOME/openlane/user_project_wrapper/macro.cfg
REPO_HOME/verilog/rtl/user_project_wrapper.vmprj1 2590 2000 N
mprj2 2590 1800 N
mprj3 2590 1600 N
mprj4 2590 1400 N
mprj5 2590 1200 N
ro1 1476 2458 N
# ro2 1476 2353 N
# ro3 1476 2248 N
# ro4 1476 2143 N
# ro5 1476 2038 N
# ro6 1476 1933 N
# ro7 1476 1828 N
# ro8 1476 1723 N
# ro9 1476 1618 N
# ro10 1476 1513 N
# ro11 1476 1408 N
# ro12 1476 1303 N
# ro13 1476 1198 N
# ro14 1476 1093 N
# ro15 1476 988 N
# ro16 1476 884 N// 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
`default_nettype none
/*
*-------------------------------------------------------------
*
* user_project_wrapper
*
* This wrapper enumerates all of the pins available to the
* user for the user project.
*
* An example user project is provided in this wrapper. The
* example should be removed and replaced with the actual
* user project.
*
*-------------------------------------------------------------
*/
module user_project_wrapper #(
parameter BITS = 32
) (
`ifdef USE_POWER_PINS
inout vdda1, // User area 1 3.3V supply
inout vdda2, // User area 2 3.3V supply
inout vssa1, // User area 1 analog ground
inout vssa2, // User area 2 analog ground
inout vccd1, // User area 1 1.8V supply
inout vccd2, // User area 2 1.8v supply
inout vssd1, // User area 1 digital ground
inout vssd2, // User area 2 digital ground
`endif
// Wishbone Slave ports (WB MI A)
input wb_clk_i,
input wb_rst_i,
input wbs_stb_i,
input wbs_cyc_i,
input wbs_we_i,
input [3:0] wbs_sel_i,
input [31:0] wbs_dat_i,
input [31:0] wbs_adr_i,
output wbs_ack_o,
output [31:0] wbs_dat_o,
// Logic Analyzer Signals
// input [127:0] la_data_in,
// output [127:0] la_data_out,
// input [127:0] la_oenb,
// IOs
input [`MPRJ_IO_PADS-1:0] io_in,
output [`MPRJ_IO_PADS-1:0] io_out,
output [`MPRJ_IO_PADS-1:0] io_oeb,
// Analog (direct connection to GPIO pad---use with caution)
// Note that analog I/O is not available on the 7 lowest-numbered
// GPIO pads, and so the analog_io indexing is offset from the
// GPIO indexing by 7 (also upper 2 GPIOs do not have analog_io).
inout [`MPRJ_IO_PADS-10:0] analog_io,
// Independent clock (on independent integer divider)
// input user_clock2,
// User maskable interrupt signals
// output [2:0] user_irq
);
/*--------------------------------------*/
/* User project is instantiated here */
/*--------------------------------------*/
wire [15:0] x1, x2, x3, x4, x5;
sky130_osu_ring_oscillator_mpr2aa_8_b0r1 ro1(
`ifdef USE_POWER_PINS
.vccd1(vccd1),
.vssd1(vssd1),
`endif
.s1(io_in[0]),
.s2(io_in[1]),
.s3(io_in[2]),
.s4(io_in[3]),
.s5(io_in[4]),
.start(io_in[5]),
.X1_Y1(x1[0]),
.X2_Y1(x2[0]),
.X3_Y1(x3[0]),
.X4_Y1(x4[0]),
.X5_Y1(x5[0])
);
// sky130_osu_ring_oscillator_mpr2at_8_b0r1 ro2(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[1]),
// .X2_Y1(x2[1]),
// .X3_Y1(x3[1]),
// .X4_Y1(x4[1]),
// .X5_Y1(x5[1])
// );
// sky130_osu_ring_oscillator_mpr2ca_8_b0r1 ro3(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[2]),
// .X2_Y1(x2[2]),
// .X3_Y1(x3[2]),
// .X4_Y1(x4[2]),
// .X5_Y1(x5[2])
// );
// sky130_osu_ring_oscillator_mpr2ct_8_b0r1 ro4(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[3]),
// .X2_Y1(x2[3]),
// .X3_Y1(x3[3]),
// .X4_Y1(x4[3]),
// .X5_Y1(x5[3])
// );
// sky130_osu_ring_oscillator_mpr2ea_8_b0r1 ro5(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[4]),
// .X2_Y1(x2[4]),
// .X3_Y1(x3[4]),
// .X4_Y1(x4[4]),
// .X5_Y1(x5[4])
// );
// sky130_osu_ring_oscillator_mpr2et_8_b0r1 ro6(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[5]),
// .X2_Y1(x2[5]),
// .X3_Y1(x3[5]),
// .X4_Y1(x4[5]),
// .X5_Y1(x5[5])
// );
// sky130_osu_ring_oscillator_mpr2xa_8_b0r1 ro7(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[6]),
// .X2_Y1(x2[6]),
// .X3_Y1(x3[6]),
// .X4_Y1(x4[6]),
// .X5_Y1(x5[6])
// );
// sky130_osu_ring_oscillator_mpr2ya_8_b0r1 ro8(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[7]),
// .X2_Y1(x2[7]),
// .X3_Y1(x3[7]),
// .X4_Y1(x4[7]),
// .X5_Y1(x5[7])
// );
// sky130_osu_ring_oscillator_mpr2aa_8_b0r2 ro9(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[8]),
// .X2_Y1(x2[8]),
// .X3_Y1(x3[8]),
// .X4_Y1(x4[8]),
// .X5_Y1(x5[8])
// );
// sky130_osu_ring_oscillator_mpr2at_8_b0r2 ro10(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[9]),
// .X2_Y1(x2[9]),
// .X3_Y1(x3[9]),
// .X4_Y1(x4[9]),
// .X5_Y1(x5[9])
// );
// sky130_osu_ring_oscillator_mpr2ca_8_b0r2 ro11(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[10]),
// .X2_Y1(x2[10]),
// .X3_Y1(x3[10]),
// .X4_Y1(x4[10]),
// .X5_Y1(x5[10])
// );
// sky130_osu_ring_oscillator_mpr2ct_8_b0r2 ro12(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[11]),
// .X2_Y1(x2[11]),
// .X3_Y1(x3[11]),
// .X4_Y1(x4[11]),
// .X5_Y1(x5[11])
// );
// sky130_osu_ring_oscillator_mpr2ea_8_b0r2 ro13(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[12]),
// .X2_Y1(x2[12]),
// .X3_Y1(x3[12]),
// .X4_Y1(x4[12]),
// .X5_Y1(x5[12])
// );
// sky130_osu_ring_oscillator_mpr2et_8_b0r2 ro14(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[13]),
// .X2_Y1(x2[13]),
// .X3_Y1(x3[13]),
// .X4_Y1(x4[13]),
// .X5_Y1(x5[13])
// );
// sky130_osu_ring_oscillator_mpr2xa_8_b0r2 ro15(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[14]),
// .X2_Y1(x2[14]),
// .X3_Y1(x3[14]),
// .X4_Y1(x4[14]),
// .X5_Y1(x5[14])
// );
// sky130_osu_ring_oscillator_mpr2ya_8_b0r2 ro16(
// `ifdef USE_POWER_PINS
// .vccd1(vccd1),
// .vssd1(vssd1),
// `endif
// .s1(io_in[0]),
// .s2(io_in[1]),
// .s3(io_in[2]),
// .s4(io_in[3]),
// .s5(io_in[4]),
// .start(io_in[5]),
// .X1_Y1(x1[15]),
// .X2_Y1(x2[15]),
// .X3_Y1(x3[15]),
// .X4_Y1(x4[15]),
// .X5_Y1(x5[15])
// );
mux16x1_project mprj1 (
`ifdef USE_POWER_PINS
.vccd1(vccd1), // User area 1 1.8V power
.vssd1(vssd1), // User area 1 digital ground
`endif
.data_in(x1[15:0]),
.select(io_in[6:9]),
.y(io_out[0])
);
mux16x1_project mprj2 (
`ifdef USE_POWER_PINS
.vccd1(vccd1), // User area 1 1.8V power
.vssd1(vssd1), // User area 1 digital ground
`endif
.data_in(x2[15:0]),
.select(io_in[6:9]),
.y(io_out[0])
);
mux16x1_project mprj3 (
`ifdef USE_POWER_PINS
.vccd1(vccd1), // User area 1 1.8V power
.vssd1(vssd1), // User area 1 digital ground
`endif
.data_in(x3[15:0]),
.select(io_in[6:9]),
.y(io_out[0])
);
mux16x1_project mprj4 (
`ifdef USE_POWER_PINS
.vccd1(vccd1), // User area 1 1.8V power
.vssd1(vssd1), // User area 1 digital ground
`endif
.data_in(x4[15:0]),
.select(io_in[6:9]),
.y(io_out[0])
);
mux16x1_project mprj5 (
`ifdef USE_POWER_PINS
.vccd1(vccd1), // User area 1 1.8V power
.vssd1(vssd1), // User area 1 digital ground
`endif
.data_in(x5[15:0]),
.select(io_in[6:9]),
.y(io_out[0])
);
endmodule // user_project_wrapper
`default_nettype wireUsing these modified files should get you through those warnings and error.
d-m-bailey
commented
5 months ago @lrburle those are some pretty large lef files. I doubt that you need/want all that information. Are you creating them in magic?
kareefardi
commented
5 months ago @lrburle Thanks. That got me going. A couple of things:
First, since now the macro power pins are on met1, you need to add connect statements from met1 to met4 and met1 to met5 (I am not sure if you need them both, but I guess it doesn't hurt).
add_pdn_connect \
-grid macro \
-layers "met1 met4"
add_pdn_connect \
-grid macro \
-layers "met1 met5"If you do that, you will get these warnings:
[WARNING PDN-0110] No via inserted between met1 and met5 at (1476.0000, 2466.5750) - (1557.7800, 2466.8800) on vssd1
[WARNING PDN-0110] No via inserted between met1 and met5 at (1476.0050, 2462.1350) - (1557.7800, 2462.6800) on vccd1If you jump to one of those locations, you will notice that intersection between met1 and met5 has a height of about 0.5.
As @d-m-bailey mentioned before this area seems too small. The PDN tool has to connect down from met5 to met1 through vias while obeying min width, spacing and enclosure. For example, via4 has a min width of 0.8 so it wouldn't fit that area.
lrburle
commented
5 months ago @d-m-bailey Unfortunately, magic doesn't fully support curvilinear metal traces and some of my custom layouts have curvilinear traces rather than the conventional rectilinear traces for the metal connections within the layout. When I attempted to build a lef using magic for the layouts using rectilinear, magic would hang up. So, I opted to use the Cadence Abstract tool instead to circumvent this issue.
@kareefardi Roger. So, I should make my power rails in my layouts much larger to accommodate the metal5 and metal4 via width requirements. Looks like I should modify the horizontal strap spacing (metal5) as well to better align with the cells.
lrburle
commented
5 months ago @kareefardi @d-m-bailey Turns out the size of the area was the main issue:
I increased the size of my power rails to 1.5 microns and the metal5 straps seem to be content.
However, it seems that the vertical metal4 straps will not pass over my layouts anymore. I used the suggested connection settings inside of the PDN config file and it produces the layout shown above.
add_pdn_connect \
-grid macro \
-layers "met1 met4"
add_pdn_connect \
-grid macro \
-layers "met1 met5"However, when I use:
add_pdn_connect \
-grid macro \
-layers "met1 met4"
The vertical metal straps will pass over the layout without an issue again but it will not connect to my power rails.
Not sure if there should be another modification to the PDN configuration file to get the metal4 strap to connect to my rails or not.
lrburle
commented
5 months ago @kareefardi @d-m-bailey I just noticed something interesting about the router:
It appears the router is ignoring the power rails when attempting to connect to the internal pins. The image depicts a via1 (sitting on top of the vssd1 rail) to connect a met2 -> via1 -> met1 layer which is ultimately routed to a pin. This unfortunately shorts this pin to ground since the power rails are on metal1. This behavior isn't desired.
One other observation, many of my cells have curvilinear metal traces. When I define my bottom vssd1 rail, this will throw an error like this:
[ERROR]: Last 10 lines:
Units: 1000
Number of layers: 13
Number of macros: 458
Number of vias: 25
Number of viarulegen: 25
[INFO DRT-0150] Reading design.
[ERROR DRT-0416] Term vssd1 of ro2 contains offgrid pin shape. Pin shape ( 1553995 2357127 ) ( 1554305 2357252 ) is not a multiple of the manufacturing grid 5.
Error: droute.tcl, 38 DRT-0416
child process exited abnormally
[ERROR]: Creating issue reproducible...However, if I add a label / pin to designs that have rectilinear traces, this error does not occur.
d-m-bailey
commented
5 months ago @lrburle concerning the ground short, the router will be using the LEF version. Can you load the lef to be sure that there is a metal1 obstruction or pin at the short location?
lrburle
commented
5 months ago @d-m-bailey Closer look at the problem area.
Here is my layout in the same area. This GDS is used to create my LEF file:
The rail itself is defined as the
vssd1 pin in this instance and there is not a pin in my layout that the via in question should be dropping to while it is routing over the rail. It is attempting to connect to a pin S4 (bottom blue via) but inadvertently, connects to my vssd1 rail when it goes from met2 to met1. Something else to note, it seems to do this because of a metal2 trace that is running horizontally with the rail. What the router should have done was to move from met2 to met3, cross the met2 trace and then go back down to met2 to connect to the via near the bottom.
Layer info for the via in question.
d-m-bailey
commented
5 months ago @lrburle klayout allows you to load a lef file. Is that what you showed above? openlane does not consider the gds when routing. maybe the layout was updated after the lef file was created.
lrburle
commented
5 months ago @d-m-bailey Getting a really strange output lef file:
Doesn't seem to have any cells in the lef file. I took the lef from the openlane/user_project_wrapper/runs/DATE_TIME/results/signoff/user_project_wrapper.lef.
Here is the lef file for reference: user_project_wrapper.lef.zip
d-m-bailey
commented
5 months ago @lrburle that looks like the top level lef that is output from openlane.
You want to look at the lef for your macro that is input to openlane. The lef file should be specified in the same config file where you place the macro.
lrburle
commented
5 months ago @d-m-bailey Here is the general area from the input lef:
The pin that is attempting to be connected is the via1 at the bottom left. There is not a pin where the via shown above should drop down to. The entire rail is labeled as a pin for vssd1.
d-m-bailey
commented
5 months ago @lrburle can you upload the gds with the error to the repo or post it here?
lrburle
commented
5 months ago @d-m-bailey It seems I can no longer recreate this issue - modifications were made to the internal pin connections to either extend or place the pins on higher metal layers to avoid this issue. Apologies. Thanks for all of your help!
Description
I'm attempting to run the Caravel flow using custom layouts. Currently, I have the
FP_PDN_MACRO_HOOKSplaced in theconfig.jsonto attempt to remedy this. However, I'm still seeing issues placing via's down from the power grid to the power rails of my custom layouts (see screenshot).Here is my config.json file: config.json
Expected Behavior
I expect vias placed on the custom layout to allow the connection of the power grid to the custom layouts.
Environment report
Reproduction material
openlane_24_01_11_08_13_logs.tar.gz
Relevant log output