On the recent open_pdks I can no longer build my d...
# openlane
d
On the recent open_pdks I can no longer build my design using openlane and there are new warnings which seem like fatal errors (probably related), I've noticed missing VGND and VPWR warnings in the synthesis_optimized.v output of my user project when it comes to an OpenSTA step: https://gist.github.com/dan-rodrigues/dcca1ed46dc284ac46d0652a3f261ea3 they did not appear in an older Nov 22 commit of open_pdks (
b427e3bd10dcdc36891ae270a1ef0bd02602c553
) https://gist.github.com/dan-rodrigues/6673cffcd67fce661ffee6f322ac9eb1 are people seeing these warnings and it just works as normal? missing power connections seems like a show stopper
t
If you tell me in which
.log
file they appeat in the
run
repo, I can check here ... if I have them
d
Thanks, it is in
opensta_post_openphysyn.log
which should be in /logs/synthesis
t
Note that I'm not on the latest open_pdk (
6547ee36754cd8e6aa0eb2de07ee10ad7e0c06e8
) or openlane (
817314be3c7996f62b6cb499e35e2107d4b822e2
) either.
d
ah yeah forgot to say...I got the same issue in
6547ee36754cd8e6aa0eb2de07ee10ad7e0c06e8
t
Copy code
OpenSTA 2.2.0 b0f0de488f Copyright (c) 2019, Parallax Software, Inc.
License GPLv3: GNU GPL version 3 <<http://gnu.org/licenses/gpl.html>>

This is free software, and you are free to change and redistribute it
under certain conditions; type `show_copying' for details.
This program comes with ABSOLUTELY NO WARRANTY; for details type `show_warranty'.
Error: cannot open '/home/tnt/.sta'.
Warning: /home/tnt/sky130/openlane_workspace/pdks/sky130A/libs.ref/sky130_fd_sc_hd/lib/sky130_fd_sc_hd__ff_n40C_1v95.lib, line 31 default_operating_condition ff_n40C_1v95 not found.
Warning: /home/tnt/sky130/openlane_workspace/pdks/sky130A/libs.ref/sky130_fd_sc_hd/lib/sky130_fd_sc_hd__ss_100C_1v60.lib, line 32 default_operating_condition ss_100C_1v60 not found.
Warning: /home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_top/runs/golden_pwr/results/synthesis/pyfive_top.synthesis_optimized.v, line 37048 module sram_1rw1r_32_256_8_sky130 not found.  Creating black box for \audio_I.fifo_I.ram_I .
Warning: /home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_top/runs/golden_pwr/results/synthesis/pyfive_top.synthesis_optimized.v, line 38516 module sky130_fd_sc_hd__tapvpwrvgnd_1 not found.  Creating black box for PHY_252.
create_clock [get_ports $::env(CLOCK_PORT)]  -name $::env(CLOCK_PORT)  -period $::env(CLOCK_PERIOD)
set input_delay_value [expr $::env(CLOCK_PERIOD) * $::env(IO_PCT)]
set output_delay_value [expr $::env(CLOCK_PERIOD) * $::env(IO_PCT)]
puts "\[INFO\]: Setting output delay to: $output_delay_value"
[INFO]: Setting output delay to: 3.0
puts "\[INFO\]: Setting input delay to: $input_delay_value"
[INFO]: Setting input delay to: 3.0
set clk_indx [lsearch [all_inputs] [get_port $::env(CLOCK_PORT)]]
#set rst_indx [lsearch [all_inputs] [get_port resetn]]
set all_inputs_wo_clk [lreplace [all_inputs] $clk_indx $clk_indx]
#set all_inputs_wo_clk_rst [lreplace $all_inputs_wo_clk $rst_indx $rst_indx]
set all_inputs_wo_clk_rst $all_inputs_wo_clk
# correct resetn
set_input_delay $input_delay_value  -clock [get_clocks $::env(CLOCK_PORT)] $all_inputs_wo_clk_rst
#set_input_delay 0.0 -clock [get_clocks $::env(CLOCK_PORT)] {resetn}
set_output_delay $output_delay_value  -clock [get_clocks $::env(CLOCK_PORT)] [all_outputs]
# TODO set this as parameter
set_driving_cell -lib_cell $::env(SYNTH_DRIVING_CELL) -pin $::env(SYNTH_DRIVING_CELL_PIN) [all_inputs]
set cap_load [expr $::env(SYNTH_CAP_LOAD) / 1000.0]
puts "\[INFO\]: Setting load to: $cap_load"
[INFO]: Setting load to: 0.01765
set_load  $cap_load [all_outputs]
tns 0.00
wns 0.00
d
huh ok, no VPWR/GND warnings... I think the open_pdks make / install blows away the sky130A/ dir before copying so not sure if anything "bad" is leftover..
can you share your skywater-pdks commit you used?
not sure what else to check
t
f1d096dac23d8c403296f0731be57fb0a7bb652a
There are no mention of
VPWR
/
VGND
in my
pyfive_top.synthesis_optimized.v
(which AFAIK is expected at that stage)
a
dumb question: you haven't moved the dir after
make install
have you?
d
hm I'm at
ca58d58c07ab2dac53488df393da633fd5fb9a02
so I'll try again with yours
a
(when
open_pdks
generates
sky130A
it hardcodes the paths to your
skywater-pdk
dir... i hit that early on)
d
that said I don't see much change apart from some build system stuff
yeah I've kept it in the same sky130A dir, I've run into that issue before too
t
Yeah I doubt the PDK version would make any difference.
Is
<https://github.com/dan-rodrigues/caravel-vdp-lite/>
up to date ?
d
Magic 8.3 revision 87 - Compiled on Mon Nov 23 17:53:03 UTC 2020.
magic is involved in the open_pdks setup, here's what I got from the included docker image in openlane
just checking now
Yes, that should be the config that produces that included GDS/LEF after
make vdp_lite_user_proj
it looks up to date
t
err reduce.hex not found
Oh it wants it in th cwd that's ... weird.
d
there's a symlink in /openlane to it, I'd like a neater way to specify the
$readmemh
file since AFAIK Yosys just checks the cwd when searching
if I run make form /openlane it works here and seems to pick up the symlink in that dir
t
yeah I don't run with docker so I was calling
flow.tcl
in my install directly.
Started ... gotta run an errand for 10 min, we'll see results them.
👍 1
yeah it got OOM'd
But it's in the
/opensta_spef.log
step here
looking at my
xxx.synthesis_preroute.v
file, the cells don't have the
VPWR
/
VGND
/
VPB
/
VNB
ports for me.
d
I get the OOM too but weird that it's in a different step... so you do not see the
Warning: /project/openlane/vdp_lite_user_proj/runs/01-12_06-34/results/synthesis/vdp_lite_user_proj.synthesis_optimized.v, line 54 instance _19673_ port VGND not found.
logs?
(in
opensta_post_openphysyn.log
)
t
Mmm, my
synthesis_optimized
verilog (for the vdp project) doesn't have the VPWR/VGND ports.
So something is causing those to be added too early in the flow.
d
huh, bizarre that the open_pdks commit is the difference between it working and not working in that case
I manually nuked /sky130A myself and am doing another run from
master
, and ensuring openlane is the same as yours (think it was
develop
)
t
did you look at the change log ?
d
the most relevant thing I could spot is this: https://github.com/RTimothyEdwards/open_pdks/commit/db8759823e490cc7031d124e3688a424cac26892#diff-d1a4ecdae6460af432395e8a432df884a481e18fa3810c02a165bbac32272decR5 but I'm not familiar with the systems involved here and can't really comment on how / if / why that would be related
I wouldn't mind git-bisecting it but the time spent would be absolutely killer
hmm I do see some pdn changes in caravel which I haven't merged in: https://github.com/efabless/caravel/commit/6aea300df81ca8fc276178670339fb74895413b8 I'll try merging latest caravel update my pdn.cfg to match
t
Mmm ... interesting. I do have a custom
pdn.tcl
in my project so the one from open_pdk isn't used for me.
d
yeah that might be part of my issue with the old pdn.tcl
I did notice that manually removing /sky130A and doing open_pdks make-install got me past that with my (old) caravel design..I won't rely on the script for that anymore, did seem ok so far
t
I know in newer openlane the position of
gen_pdn
call changed aswell which would require updating the
interactive.tcl
which is one reason I'm not updating ATM, I don't want ot have to mess with that while it works.
d
but I should upgrade the caravel regardless. DRC issues aside, the
make ship
complete GDS I have is probably junk now anyway
right that's good to know about openlane, I'm staying on
develop
for now
t
well it's on
develop
that it changed, over the weekend 😅
but yeah, I updated caravel to latest yesterday before doing the integration of everything.
d
my bad I confused the repo I was talking about
openlane here is actually
817314be3c7996f62b6cb499e35e2107d4b822e2
which seems like a "stable" one
ok I just scrolled to the rest of the thread, I think we're on the same commit here
a
@drr: https://github.com/RTimothyEdwards/open_pdks/pull/71 Maybe this would answer your question. It has been merged. However, I wouldn't recommend moving forward with the PDK version until we update it in either branches of either repos (usually I run some tests first before updating the versions just to make sure everything will still be stable).
👍 1
t
@Amr Gouhar I'm actually wondering what that whole section in the pdn config does ? I mean I don't have it (it wasn't there at all a week ago when I originally created my custom
pdn.tcl
based on
common_pdn.tcl
) and I didn't really notice any issue.
I also have the
set ::rails_mlayer "met1" ;
which has been removed recently too.
a
@tnt: What I know is that this section will add the instantiations of the power pins and their nets to the DEF and that they would be reflected in the DEF and the netlists from that point of the flow onward. Unlike what we used to do which include them in the verilog after detailed routing and spef extraction. However, @Ahmed Ghazy will probably be able to give a more detailed answer, because I was unable to find the documentation for this section :--). The
set ::rails_mlayer "met1" ;
was removed since we specify it anyways in the
stdcell
section.
👍 1
Thinking about it again now, I guess I could've gone with controlling the flag in this line https://github.com/efabless/openlane/blob/ed1c59bdf7045c22c6c6ad64028daebee5947cdd/scripts/openroad/or_write_verilog.tcl#L24 based on the flow stage to avoid this.
t
At least this doesn't require the PDNGen patch which is required for the other way IIUC.
a
@tnt: I made the pdngen hack the default (on develop) until I (or the OpenROAD guys) deal with it in OpenDB.