FP_PDN_CFG Met3 and Met4 not connecting to macro's defined power rails

[jchin2]

Description

I have a basic building block of a macro that I want to connect to the PDN rails. The macro is analog and adiabatic in nature which uses trapezoidal wave as power. VDD rail (Met3) in this macro is floating and is there to satisfy PDN_MACRO_HOOKS. GND rail (Met3) is planned to be connected to analog ground either via vssa or GPIO pin for external ground. All of this is done with the caravel_user_project_analog.
All the input and output pins are recognized properly by flow.tcl and are connected. The following image shows a graphic of the macro and the main VDD and GND rail not connected. Yellow highlight should be the main PDN rails for the buffer and decaps.

I made, renamed and point to a copy of pdn_cfg.tcl to have the following:

    -grid macro \
    -layers "met3 met4"

Openlane seems to refuse connect to the macro's GND or VDD rail which causes lvs mismatch with macro's VDD rail. LVS reports pin list matches. I have tried making a separate ground pin for the macro's GND rail. Openlane connects to the pin but lvs fails at matching the netlist for VDD so I shelved that and continued with its current iteration.

Expected Behavior

Openlane to recognize macro's VDD and GND rail (Met3) and no netlist mismatch.

Environment report

Kernel: Linux v6.2.0-26-generic
Distribution: ubuntu 22.04
Python: v3.11.3 (OK)
Container Engine: docker v24.0.5 (OK)
OpenLane Git Version: d054702b2cce04761cc2bc598f6b95c9d8ca7c6c
pip: INSTALLED
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

d054702 2023-07-19T16:09:15+03:00 remove `unset_propagated_clock` (#1908) - passant5 -  (grafted, HEAD, tag: 2023.07.19)
---
Git Remotes

origin	https://github.com/The-OpenROAD-Project/OpenLane (fetch)
origin	https://github.com/The-OpenROAD-Project/OpenLane (push)

Reproduction material

current_state_08172023.zip

1. Original layout is generated with Klayout and can be found in Klayout_GDS folder.
2. Magic used to read the GDS file
   lef command: lef write bitfour_EESPFAL -tech -hide 200 -toplayer -pinonly 200
   magic used to write GDS file and used for blackbox macro located in GDS folder
3. Makefile included in the folder belongs to ~/caravel_user_project_analog/openlane/ and is a copy of caravel_user_project/openlane/ makefile.
4. make openlane was executed in caravel_user_project_analog with export OPENLANE_TAG=2023.07.19
5. make blackbox_test_2 to run

Relevant log output

[STEP 40]
[INFO]: Running LVS (log: ../home/jchin2/caravel_user_project_analog/openlane/blackbox_test_2/runs/23_08_17_09_13/logs/signoff/40-lvs.lef.log)...
[ERROR]: There are LVS errors in the design: See '../home/jchin2/caravel_user_project_analog/openlane/blackbox_test_2/runs/23_08_17_09_13/reports/signoff/40-blackbox_test_2.lvs.rpt' for a summary and '../home/jchin2/caravel_user_project_analog/openlane/blackbox_test_2/runs/23_08_17_09_13/logs/signoff/40-lvs.lef.log' for details.
[ERROR]: Step 40 (lvs) failed with error:
-code 1 -level 0 -errorcode NONE -errorinfo {
    while executing
"throw_error"
    (procedure "quit_on_lvs_error" line 13)
    invoked from within
"quit_on_lvs_error -rpt $count_lvs_rpt -log $log"
    (procedure "run_lvs" line 76)
    invoked from within
"run_lvs"
    (procedure "run_lvs_step" line 10)
    invoked from within
"run_lvs_step"} -errorline 1

[kareefardi]

With the default configuration, vertical met4 stripes have a high pitch. There is no vertical met4 stripe that is passing through the macro. This is the cause of your LVS issue. If you decrease the vertical pitch by changing FP_PDN_VPICTCH to, for example, 50, it will connect to the macro. This can be changed through FP_PDN_VPITCH.

Note:
Inside your macro itself. VDD is unconnected.

[jchin2]

Thank you for looking into the issue. VDD is there as a floating pin, to fulfill pdn_macro_hooks pins and nets requirements.
I have confirmed it has connected on my end!
Follow up questions, would it be wise to make direct changes to the copy for pdn_cfg.tcl (pdn_cfg_here.tcl) such as -pitch $::env(FP_PDN_VPITCH) to be -pitch $::env(50) for a limited change? Another question is this macro has a digital counterpart where we also want it to have it's own ground for external power measurements. Would assigning the current macro and its digital version to vssa1 and vssa2 respectively be possible? Or it is recommended to have dummy pins like how VDD is existing within the current macro?

[kareefardi]

Thank you for looking into the issue. VDD is there as a floating pin, to fulfill pdn_macro_hooks pins and nets requirements. I have confirmed it has connected on my end! Follow up questions, would it be wise to make direct changes to the copy for pdn_cfg.tcl (pdn_cfg_here.tcl) such as -pitch $::env(FP_PDN_VPITCH) to be -pitch $::env(50) for a limited change?

In general, it is better to use variables and avoid having hard coded values. So I advise against using -pitch $::env(50).

Would assigning the current macro and its digital version to vssa1 and vssa2 respectively be possible? Or it is recommended to have dummy pins like how VDD is existing within the current macro?

I am not sure that I follow. Do you mean you want to have two ground domains and assign a different ground for each macro ?

[jchin2]

Do you mean you want to have two ground domains and assign a different ground for each macro ?

That's the idea. We want to be able to measure the two macro's power in their own domain. We have thought of having the macro's ground to GPIO pins for better way to access/measure them. I was wondering how caravel's vssa1 and vssa2 are connected.
We will be using verilog to control input and output signals going in and out of the macros. The adiabatic macro's output signal is trapezoidal in nature while the digital counterpart is a rect wave. To sum it up, the input-output-control-verilog code is powered using vccd1 and vssd1 rails. While the macros will be via GPIO pins. I see in the caravel harness documentation https://caravel-harness.readthedocs.io/en/latest/pinout.html , there is user area 1 and user area 2. The question is would having the macros use vssa1 and vssa2 achieve the same thing as using GPIO pins as ground?

[jchin2]

Hi @kareefardi , I made some changes to the PDN rails and the ground pin name for the macro. I want the macro's ground to be connected to a GPIO pin where I named it GND_gpio. The PDN rails VDD and GND are now floating pins.
Currently the LVS error is it saying circuit 1 netlist doesn't match.

The strange thing is openlane connects the pin properly which can be seen in the following image but netlist is not same...?

I have included the .zip file in this message. I'm pretty certain the PDN has been taken care of since openlane connects to the floating VDD and GND rails. Also the GND_gpio pin appears to be connected to the macro. Would you mind checking it?
current_state_08192023.zip